3. UNIT TESTING Arrange-Act-Assert
BASICS a pattern for arranging and
formatting code in UnitTest
methods:
Arrange http://c2.com/cgi/wiki?ArrangeActAssert
Arrange all necessary preconditions
Act and inputs.
Act on the object or method under
Assert test.
Assert that the expected results
have occurred.
5. BDD
WHAT IS IT?
TDD with some structure
• Test names should be sentences
• Tests should be focused
• Tracing requirements, executable acceptance criteria
6. STORY Feature: Short clear
BASED As an actor of the system
TESTING I want to perform some action
In order to realize some business value
User story Scenario: Some business situation
Given some context
And some other condition
When the actor perform an action
Acceptance Then the outcome is achieved
Criteria And some other outcome is achieved
Scenario: Some other situation related to the
same story
7. USER STORY Feature: Account transfer
EXAMPLE As a customer
I want to transfer money between accounts online
In order to avoid having to telephone my bank to carry do this
Scenario: Account has required funds
Given the source account is sufficient
And the customer has signed up to online banking
When the customer transfers money between accounts
Then the target account is credited immediately
And the source account is debited immediately
Scenario: Account has insufficient funds
Given the source account is insufficient funds...
9. ENTER
MSPEC
CONTEXT SPECIFICATION FRAMEWORK
CONTEXT == ARRANGE or GIVEN
SPECIFICATION == ASSERT or THEN
DEVELOPER CENTRIC
BETTER FOR UNIT TESTING
10. TEST when_describe_context {
STRUCTURE Establish context = () Arrange Given
Because of = () =...
Act When
It should_...() =...
Assert Then
It should_...() =...
Cleanup test_data () =...
}
11. INSTALLATION
Using chocolatey:
cinst machine.specifications
run InstallResharperRunner.7.1
Resharper live templates
Resharper settings – see resources
13. TESTING Behaves_likeTBehavior
BEHAVIOR
[Behaviors]
public class AccountInCredit
{
protected static Account account;
It should_have_a_positive_balance = () =
account.Balance.ShouldBeGreaterThan(0m);
}
14. CODE
BREAK
Creating an mspec test using behaviors
15. MACHINE
FAKES
Integrates machine.specifications and mocking
Auto-mocking container
Choose between:
RhinoMocks, Moq, NSubstitue and FakeItEasy
Install-Package machine.specifications.moq
16. MACHINE FAKES
WITHFAKES
WithFakes
Base class giving you access to
AnTFake or SomeTFake to create fakes
WhenToldTo(x=x.foo).Return(3) // create an
expectation
WasToldTo(x=x.foo) // verfiy an expectation
ParamT
21. CODE
BREAK
Creating a test reusing context setup code.
22. MSPEC
ALT
SHARPDEVELOP
TEAM CITY
COMMAND LINE
MSBUILD TASK
23. LESSONS
I LEARNED
Treat test code like production code
Use DI and Factories
Be wary of inheritance
Tests should be simple
Don’t be scared to delete tests
Nice to see so many people here.This is the first time I’ve given a technical talk, so please go easy on me. On the other hand please also interrupt and throw in questionsIt would be great to have a talk, this isn’t meant to be death by powerpointHaving said that I have 25 slides, almost all of them have no valuable contentTalk is going to cover . Arrange act assert (who here knows that) . Intro to BDD (behaviour driven development) . Quick look at specification and story based testing using specflow, similar JbeHave and RSPec .A fast run through of the major features of the mspec and machine.fakes project
I’m not religious this is just the way I like to program if left to play on my own in the develop sand pitHowever more and more clients are demanding that programmers are fluent in TDD/BBD mspec, specflow or fitnesseI also love tools, passionate about doing things quickly / optimizing Out of interest how many people use nuget?nuget IT’s new in the last say 3 years and has really changed how accessbile open source projects are to .net dev.chocolatey
Give a bit of background Dan North etc….Test names should be sentencesSelf documenting, most developers write the test name in business language, and should in terms of desired behaviorFocused What do we mean here, well formed assertions beginning with should_..... If you find your tests are getting complicated and don’t fit a simple arrange, act , assert it might be an indication your class is trying to do too much and might need some form of composition. So refactor and test the interaction with the composed class instead
A second fundamental choice made by BDD is how desired behaviour should be specified.And you can see that you have a good fit here with AgileThis is an example template and is based on user story specifications, importantly expressed in business language expressing the desired behaviour and business value achieved.
Writing feature files can be done by anyone! Normally best done by QA or SDET roles
Context specification framework is a fancy way for saying it’s a framework that helps distinguish context and the specification. The context being the arrange And the specificatoin being the assert partThis is what MSPEC does really well.MSPEC supports behaviour driven designBut unlike Spec flow, it doesn’t allow the business to create the specification and is more developer focused.More refactor friendly
Looks funny to begin with Statics Lambda’s but you get used to it in the end
Bare bones you can just use the command lineVisual studio integration with resharper, requires installation
Allows you to encapsulate your assertions, also makes the test more readable.Important to note:Step1 : Create a new class with a behavior attributeStep2 : Define your assertionsStep3 : Create the context variable in the behavior as protected with the same name as the associated test class
Installation via nuget.Provides an integration layer between machine fakes and your mocking layer and also abstracts to some degree which framework you use
A lot of test code an get repetitiveRe-use through composition is normally the best way to go, and this is With (classes allow you to do) using OnEstablish
Treat test code like production codeSame level of respect and rigorUse DI and FactoriesInstantiating objects in test code, is likely to make your tests brittle and a pain to maintainBe wary of inheritanceCan obscure important meaning of your