Better Testing Through Behaviour


Published on

Test Driven Development (TDD) is a well established development practice that provides significant benefits throughout the entire software development process. While TDD provides many advantages, it is often met with resistance and can be easily misused. Behaviour Driven Development (BDD) is a refinement to TDD that shifts the emphasis from testing to specification. BDD practitioners cite several advantages to this approach covering organisational, managerial and technical TDD concerns. This paper explores these benefits using Instinct, a purpose built open source Java BDD framework. Instinct provides flexible annotation of behaviour contexts, specifications and actors; automatic creation of test doubles and test subjects; a state and behaviour expectation API; JUnit test runner integration; Ant support and an IntelliJ IDEA plugin.

Published in: Business, Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Better Testing Through Behaviour

  1. 1. Better Testing Through Behaviour Open Source Developers’ Conference November 2007 Tom Adams Workingmouse
  2. 2. “The act of writing a unit test is more an act of design than of verification. It’s also more an act of documentation than of verification. The act of writing a unit test closes a remarkable number of feedback loops, the least of which is the one pertaining to verification of function.” Robert C. Martin
  3. 3. Why do I care? I. Better process •Workflow is easier, IDE-a-bility, simpler •Supporting infrastructure & language that guides you down the correct path II. Better results •Splitting of state into separate contexts means understanding •Nicer syntax, less code to mentally parse •Readable results
  4. 4. Test driven development •Development practice, arising out of XP’s test first approach •Incremental process - test, code, refactor, test code, refactor… •Drives implementation - improved quality, low coupling, high cohesion •Comprehensive regression test suite •Focus on design? •Focus on documentation? •Focus on behaviour?
  5. 5. Problems? •Too much time/money, optional extra •Overlapping with traditional QA testers •Developers require training •Developer resistance •Vocabulary difference
  6. 6. Problems? •Test vocabulary affects thinking •Intent not clear •Design focus obscured •Documentation •1-1 mapping of test/production code •Tight tests coupled to code •Repetitive infrastructure setup •Where to start?
  7. 7. BDD is just TDD •Coined by Dan North - JBehave first BDD framework •Development practice, arising out agile methodologies •Refinement of TDD that shifts the emphasis from testing to specification •Frameworks - JBehave, RSpec, Instinct, JDave, NSpec, GSpec, beanSpec, JSSpec, DSpec, MissingBDD, PHPSpec, Specs, Specipy
  8. 8. class ACsvFileReaderWithNothingToRead { @Subject CsvFileReader csvFileReader; @Mock CsvFile csvFile; @Stub CsvLine[] noLines; @Specification void returnsNoLines() { expect.that(new Expectations() {{ one(csvFile).hasMoreLines(); will(returnValue(false)); ignoring(csvFile).close(); }}); expect.that(csvFileReader.readLines()).equalTo(noLines); } }
  9. 9. class AnEmptyStack { @Subject Stack<Object> stack; @Dummy Object object; @Specification void isEmpty() { expect.that(stack.isEmpty()).isTrue(); } @Specification void isNoLongerBeEmptyAfterPush() { stack.push(object); expect.that(stack.isEmpty()).isFalse(); } @Specification(expectedException = IllegalStateException.class, withMessage = quot;Cannot pop an empty stackquot;) void throwsExceptionWhenPopped() { stack.pop(); } }
  10. 10. AnEmptyStack - isEmpty - isNoLongerBeEmptyAfterPush - throwsExceptionWhenPopped ANonEmptyStack - isNotEmpty - isNoLongerFullAfterPoppingAllElements - throwsExceptionWhenANullIsPushed - popsPushedValue - shouldPopSecondPushedValueFirst - leavesValueOnStackAfterPeek
  11. 11. Ubiquitous language •Language has an impact on how you think about something •Known in linguistics as the Sapir-Whorf hypothesis •There is “a systematic relationship between the grammatical categories of the language a person speaks and how that person both understands the world and behaves in it” •The language used to describe software constructs has an impact on how we create those constructs, e.g. good APIs, well named variables
  12. 12. Ubiquitous language •Getting the words right - naming of classes, methods and variables •Borrows from domain driven development (DDD) •Bridges gap between technical and business artefacts •Captures the behaviour of the domain using clear and concise syntax •Forms consensus around domain artefacts and run-time behaviour
  13. 13. private void testRunnerSendsSpecifiationResultsToOutput() { assertTrue(quot;Expected to find context namequot;, runnerOutput.contains(className)); } private void sendsSpecifiationResultsToOutput() { expect.that(runnerOutput).containsString(className); }
  14. 14. assertEquals(1, map.size()); assertTrue(map.containsKey(1000)); assertEquals(fileNames, map.get(1000)); expect.that(map).hasSize(1); expect.that(map).containsKey(1000); expect.that(map).containsEntry(1000, fileNames);
  15. 15. public void testMethodIsAnnotated() { checkIsAnnotated(WithRuntimeAnnotations.class, Context.class, true);   checkIsAnnotated(WithoutRuntimeAnnotations.class, Context.class, false); } private void checkIsAnnotated(AnnotatedElement element, Class<?> expectedAnnotation, boolean expectingAnnotation) { AnnotationChecker annotationChecker = new AnnotationCheckerImpl();   assertEquals(expectingAnnotation, annotationChecker.isAnnotated(element, expectedAnnotation)); }
  16. 16. public void testClassIsAnnotated() { expect.that(annotationChecker.isAnnotated( WithRuntimeAnnotations.class, Context.class)).isTrue(); expect.that(annotationChecker.isAnnotated( WithoutRuntimeAnnotations.class, Context.class)).isFalse(); }
  17. 17. Design focus •Design is one of the most important aspect of TDD •TDD’d code is (usually of) higher quality that non-TDD’d code •Bugs, coupling, cohesion, maintainability, understandable, smaller, etc. •Emphasis on testing limits TDD’s uptake & effectiveness •Organisational, technical, process •Encourages you to think about design •Design is documented through ubiquitous language, contexts
  18. 18. Behaviour focus •Focused specifications •One context per “state” of subject •Minimal expectations per specification method
  19. 19. Behaviour focus •1-to-1 test-to-prod code mapping broken •“Units” gone, what’s important is the behaviour •Specification code is less coupled to production code •Easier refactoring •M-to-N mapping encouraged
  20. 20. class AnEmptyStack { void isEmpty() {} void isNoLongerBeEmptyAfterPush() {} void throwsExceptionWhenPopped() {} } class ANonEmptyStack { void isNotEmpty() {} void throwsExceptionWhenANullIsPushed() {} void popsPushedValue() {} void shouldPopSecondPushedValueFirst() {} void leavesValueOnStackAfterPeek() {} }
  21. 21. Process •Works best top-down/outside-in •Specify at the highest level first •Use top-level objects to discover the services needed from the next level down •Rinse, repeat
  22. 22. Levels •Story-level •Code-level •Mostly historical, frameworks are now adopting both approaches •Both levels are legitimate, use one or the other depending on audience
  23. 23. Scenario quot;transfer from savings account to cheque acountquot; do Given quot;my savings account balance isquot;, 100 do |balance| @savings_account = Accounts::AccountFactory.create(:savings) @savings_account.add(balance) end And quot;my cheque account balance isquot;, 50 do |balance| @cheque_account = Accounts::AccountFactory.create(:cheque) @cheque_account.add(balance) end When quot;I transferquot;, 20 do |amount| @savings_account.transfer(amount.to_i).to(@cheque_account) end Then quot;my savings account balance should bequot;, 80 do |balance| @savings_account.balance.should == balance end And quot;my cheque account balance should bequot;, 70 do |balance| @cheque_account.balance.should == balance end end
  24. 24. describe quot;non-empty Stackquot; do it quot;should return the top item when sent #peekquot; do @stack.peek.should == @last_item_added end end class ANonEmptyStack { void shouldReturnTheTopItemWhenSentPeek() { expect.that(stack.peek()).equalTo(lastItemAdded); } }
  25. 25. Instinct •Goals - explicitness, simplicity and flexibility •Code-level (currently) framework •Unified state and behaviour (mocking) expectation API (c.f. xUnit Assert) •Built in infrastructure - mocks, stubs, dummies, subjects •Formalised nomenclature •Integration - JUnit, Ant, Clover, IntelliJ IDEA
  26. 26. Instinct examples
  27. 27. Summary •Shifts the emphasis from testing to specification •Provides a ubiquitous language •Strong focus on design •Emphasises system behaviour, independent of where the behaviour resides
  28. 28. Take home I. Better process •Workflow is easier, IDE-a-bility, simpler •Supporting infrastructure & language that guides you down the correct path II. Better results •Splitting of state into separate contexts means understanding •Nicer syntax, less code to mentally parse •Readable results
  29. 29. References • • • • •