Test First Software Development

Transcription

1 Test First Software Development Jacob Kristhammar Roger Schildmeijer D04, Lund Institute of Technology, Sweden {d04jk Abstract In this in-depth study we will try to explain what Test-Driven Development (TDD) is, and why you should apply it. One of the main goal is also to show you a typical example of Test-Driven Development, also describe the stages that are invovled in TDD (The TDD cycle). And also show the difference between TDD and Behaviourial Driven Development (BDD). We will show you how to use TDD and BDD by implementing a simple datastructure called Stack. 1 Introduction A natural question to ask is why tests are needed? There are many arguments why you should use and write your own tests. One big advantage is that tests enables you to trust other programmers code. Another advantage is that tests makes is easy to see if a refactoring did or did not destroy any of your earlier implementation [4]. These two advantages are not specific only for Test-Driven Developmen. They are also advantages in more traditional testing. The main difference between TDD and traditional testing is that in TDD you write your tests before you implement your functionality. You write your test, see it fails, then you implement the feature, see that the test passes, then its time to refactor. By doing this, write the test before the implementation, this enforces the programmer to think about the requirements and hopefully produces a product with better quality. 2 The TDD cycle The origin of this TDD cycle comes from Kent Becks Test-Driven Development by Example. It s supposed to be a guideline that describes, in general, how to apply Test-driven development. The guidline is not too comprehensive, instead its supposed to be a brief introduction how TDD should be performed. 2.1 Add a test Before you start implementing a new feature you write a test for that feature. The test must unavoidably fail because the test was written before the feature was implemented. To be able to write a test, the developer must be fully aware of the specification and requirements that the feature comprise, otherwise it s hard to know what the test must test. To accomplish this its very useful to have user stories and use cases. Stories and cases that covers the customers requirements. 2.2 See the new test fail Run the new test just to see it fail sounds like a ridiculous thing to do. The importance of this step is not always so obvious. It s necessary to do this to ensure that the new test really fails, ie. turns red, and not 1

2 passes and shows the user a green light [1]. If the test passes directly how should you then know when the new feature is correctly implemented. This technique avoids the syndrome of writing tests that always pass, and therefore aren t worth much. 2.3 Implement The next step is to implement the new feature. It s time to write some code so the new test gives us green light. The code written in this step is not supposed to be perfect and will probably be replaced in the future. It is important that the code written is only designed to pass the test[2]. 2.4 See all tests pass This is a small step that only includes the running of all the test. Hopefully all tests will pass and this will make the programmer confident because this is an indication code meets the requirements. This is a good point from which to begin the final step of the cycle.[1] 2.5 Refactoring Now it s time to clean up the code. As soon as the programmer is uncertain if the refactoring has broken some functionality he/she can re-run all tests and see if something is broken or not. The refactoring might include removing of duplicated code, which is an important aspect of any software design. It can also be necessary to remove magic numbers/string that where introduced in order to make step three pass. 2.6 Repeat When the refactoring is finished it s time to start with another feature/test. When the programmer has decided which feature to implement next, the cycle starts all over again. How large, or small, each step should be is up to the programmer. As soon as the programmer feels more confident, he/she can make larges steps. When the code written to satisfy a test does not fairly quickly do so, then the step-size may have been too big, and maybe the smaller testable steps should be used instead. 3 Framework & Automatization 3.1 JUnit JUnit is a simple, open source, unit testing framework for the Java programming language. It s supposed to run repeatable tests. It was created by two famous people: Kent Beck and Erich Gamma. It s a part of the xunit framework family and is probably the most successfull. JUnit has been ported to a lot other languages like: C++ (CPPUnit), PHP (PHPUnit) and Perl (Test::Class and Test::Unit). Below is a simple JUnit-Subtraction example. public class Widget exts TestCase { public void testsubtraction() { // test if =1450: assertequals ("Subtraction", 1450, ); } } In Java 5 the same test can be made easier thanks to reflection and annotation. public class Widget public void testsubtraction() { // test if =1450: 2

3 } assertequals ("Subtraction", 1450, ); } The method testsubtraction will be discovered automatically by its Test Annotation. Another feature is that it s not necessary to prefix the test-method with the test string. 4 TDD Example Using Ruby and Test::Unit The Test Unit framework used in the example is part of Ruby s standard library and its usage is very similar to JUnit. One of the reasons for choosing ruby to demonstrate TDD is because of its clean and expressive syntax. Another reason is that we will work through the same example using RSpec in the of the paper. RSpec is a framework for Behavior Driven Development (BDD) which also is implemented in Ruby, which let us compare the differences more easily. For those not familiar with Ruby, it s a dynamic, object-oriented programming language which have been gaining a lot of ground lately. Since dynamically typed languages don t have any type safety in the same sense that languages like Java has, good tests are even more important in order to detect that sort of errors before the code is put in production. The example will cover a possible TDD workflow when implementing a simple stack library (push, pop, peek). We ll start with thinking about what operations the stack should have. All stacks should have some sort of push-operation, and this stack won t be an exception. Since the tests are supposed to be written first let s get busy. A test case is created by defining a class that exts the Ruby class Test::Unit::TestCase 1. Tests are added, in the same way they are in JUnit 2, by creating instance methods with the prefix test. require "test/unit" Listing 1: Initial test and structure class TestStack < Test : : Unit : : TestCase def test_push_one_item stack = Stack. new stack. push "foo" assert_equal ( "foo", stack. peek ) After writing the first test and running it (remember that a test should always fail before it passes) the output displayed in Listing 2 is generated. The important part of the message is that there is no constant called Stack, which simply tells us that the class we re trying to test doesn t exists at all. E Finished in seconds. Listing 2: Test results 1) Error : test_push_one_item ( TestStack ) : NameError : uninitialized constant TestStack : : Stack 1 < is the same as exts in Java 2 At least as it used to before it was possible to use annotations 3

4 stack_testunit 01. rb : 5 : in test_push_one_item 1 tests, 0 assertions, 0 failures, 1 errors After watching the first test fail, with grace, it s time to make it pass by doing the simplest thing possible. Following the advice from the first test run, let s define the and run the test again (output in listing 4). class Stack Listing 3: Add the Stack class class TestStack < Test : : Unit : : TestCase The interesting stuff is the part saying that the method push isn t defined for the. The code needed to add it is displayed in Listing 5 E Finished in seconds. Listing 4: Test results 1) Error : test_push_one_item ( TestStack ) : NoMethodError : undefined method push for #<Stack : 0 x559b0> stack_testunit 02. rb : 9 : in test_push_one_item 1 tests, 0 assertions, 0 failures, 1 errors def push ( val ) Listing 5: Add the method push to the E Finished in seconds. Listing 6: Test results 1) Error : test_push_one_item ( TestStack ) : NoMethodError : undefined method peek for #<Stack : 0 x558c0> stack_testunit 03. rb : 1 2 : in test_push_one_item 1 tests, 0 assertions, 0 failures, 1 errors Now the test tell us that there s no peek method (Listing 6). The code needed for that (Listing 7) is added too. We run the test again. And finally, a failure, which means that the test is actually working, but the assertion didn t pass (Listing 8) class def Stack peek Listing 7: Add the peek method 4

5 5

6 F Finished in seconds. Listing 8: Test results 1) Failure : test_push_one_item ( TestStack ) [ stack_testunit 04. rb : 1 5 ] : < foo > expected but was <nil >. 1 tests, 1 assertions, 1 failures, 0 errors In order to get a green bar we fake the peek method by simply letting it return what we expect (Listing 9). def peek "foo" Listing 9: Make the test pass by faking the peek method. Finished in seconds. Listing 10: Test results 1 tests, 1 assertions, 0 failures, 0 errors Finally a green bar! (Listing 10) Confident that the test is actually testing what it should, a refactoring of the stack class is done (Listing 11). After running the test, it still passes (Listing 12) and we can move along with the next thing the stack should be able to do. def = [ ] Listing 11: Refactor the Stack class def push ( val push val def last. Finished in seconds. Listing 12: Test results 1 tests, 1 assertions, 0 failures, 0 errors 6

7 By following this working pattern the rest of the stack library is implemented (to some extent) which is displayed in Listings 13 through 30 Listing 13: Add another test case class TestStack < Test : : Unit : : TestCase def test_push_many_items stack = Stack. new items = %[ foo bar baz qux ] items. each do item stack. push item assert_equal ( item, stack. peek ).. Finished in seconds. Listing 14: Test results 2 tests, 2 assertions, 0 failures, 0 errors Listing 15: Refactor the tests to eliminate duplication class TestStack < Test : : Unit : : TestCase def = Stack. new def push "foo" assert_equal ( " peek ) def test_push_many_items items = %[ foo bar baz qux ] items. each do push item assert_equal ( peek ).. Finished in seconds. Listing 16: Test results 2 tests, 2 assertions, 0 failures, 0 errors Listing 17: Add another test case class TestStack < Test : : Unit : : TestCase def test_get_size 1 0. times push "foo" } 7

8 assert_equal ( 1 size ) E.. Finished in seconds. Listing 18: Test results 1) Error : test_get_size ( TestStack ) : NoMethodError : undefined method size for #<Stack : 0 x54dbc> stack_testunit 10. rb : 3 7 : in test_get_size 3 tests, 2 assertions, 0 failures, 1 errors def size Listing 19: Add the method size to Stack... Finished in seconds. Listing 20: Test results 3 tests, 3 assertions, 0 failures, 0 errors Listing 21: Add another test case class TestStack < Test : : Unit : : TestCase def push "foo" size size assert_equal ( pop ) assert_equal ( size size ). E.. Finished in seconds. Listing 22: Test results 1) Error : test_pop_one_item ( TestStack ) : NoMethodError : undefined method pop for #<Stack : 0 =[ foo ] > stack_testunit 13. rb : 4 7 : in test_pop_one_item 4 tests, 3 assertions, 0 failures, 1 errors 8

9 def pop.... Finished in seconds. Listing 23: Add the needed pop method Listing 24: Test results 4 tests, 5 assertions, 0 failures, 0 errors Listing 25: Add another test case class TestStack < Test : : Unit : : TestCase def test_pop_on_empty_stack assert_raise ( NoMoreElementsException ) pop }. E... Finished in seconds. Listing 26: Test results 1) Error : test_pop_on_empty_stack ( TestStack ) : NameError : uninitialized constant TestStack : : NoMoreElementsException stack_testunit 15. rb : 5 6 : in test_pop_on_empty_stack 5 tests, 5 assertions, 0 failures, 1 errors class Listing 27: Add the necessary exception class NoMoreElementsException < StandardError. F... Finished in seconds. Listing 28: Test results 1) Failure : test_pop_on_empty_stack ( TestStack ) [ stack_testunit 16. rb : 5 9 ] : <NoMoreElementsException> exception expected but none was thrown. 5 tests, 6 assertions, 1 failures, 0 errors Listing 29: Change the pop method to make the test pass def pop or raise NoMoreElementsException 9

10 ..... Finished in seconds. Listing 30: Test results 5 tests, 6 assertions, 0 failures, 0 errors 5 Alternative Methods Even though TDD still is a young practice, and there s a lot of developers that doesn t even know it exists, or what it actually is, some people are all ready trying to take it to the next level. Testing has never been any developers favorite thing to do, and old habits die hard. When people are trying to adopt TDD a problem is that they are giving the testing to much attention instead of the actual behavior they are trying to implement[5]. This might not seem like that big of a problem, but in practice this leads to that less tests get written, since many developers still think its boring to write tests. Another common problem is that the test cases get written in a 1-1 correspondence with the code it s supposed to test. If the structure of the tests reflect the structure of the code, structural modifications in the production code often calls for corresponding changes in the tests. To remedy these problems, amongst other things, a special branch of TDD called Behavior Driven Development (BDD) has been suggested[5]. The big difference is that instead of thinking about verification and assertions, the developer should focus on specifications and expectations. The idea is that the test code should reflect the inted behavior of the code written, which in turn probably is specified in a set of requirements from a customer. BDD should still follow the same work cycle as TDD but instead of writing test cases the developer specifies expectations and specifications. Hopefully this will lead to tests that are less coupled with the implementations and match better with the requirements. Since the testing code is written as specifications the code also serves as good documentation of what the code actually do. Newcomers to TDD often feel that writing the test before the code is working backwards. By taking a step away from the testing- and verification mindset and instead think of the tests as specifications of what the code should be able to do, the process doesn t feel that backwards anymore.[3] Just like normal TDD, BDD needs some sort of supporting framework to automate the process of specifying expectations and running them. BDD is still a pretty new concept but a few different frameworks all ready exists 3. RSpec 4 is a BDD framework that is very popular in the Ruby community and it is actively developed and new features are added all the time. One of the important ideas with of RSpec is that the code should be very verbose and readable in order to give the feeling that you are specifying behavior rather than writing tests. 3 JBehave, NSpec, Specter

11 6 RSpec Example To make things a bit clearer we shall this paper with the same example stack implementation as in section 4. The following just serves as a demonstration of what it might look like when using BDD and RSpec together with the same principles as TDD (fail, pass, refactor). Some steps are presented as one in order to save space, but the steps are very similar to those in section 4. Pay attention to the way the specification resembles written text e.g. requirements. The specifications written with RSpec can be thought of as requirements written in such a precise way that it s possible to execute them. It s also noteworthy how the output from the test runs communicates what the code does and hence servers as good documentation. class Stack Listing 31: Add first specification and the stack class describe Stack do it " should be able to pop one item to the top" do Figure 1: Test output 11

12 class Stack Listing 32: Implement the specification describe Stack do it " should be able to pop one item to the top" do stack = Stack. new stack. push "foo" stack. peek. should == "foo" Figure 2: Test output 12

13 Listing 33: Added the push and peek methods and faked the output def push ( val ) def peek "foo" describe Stack do it " should be able to pop one item to the top" do stack = Stack. new stack. push "foo" stack. peek. should == "foo" Figure 3: Test output 13

14 def = [ ] Listing 34: Refactored the implementation def push ( val push val def last describe Stack do before : each = Stack. new it " should be able to push one item to the top" push peek. should == "foo" it " should be able to push many items" do items = %[ foo bar baz qux ] items. each do push peek. should == item Figure 4: Test output 14

15 def = [ ] Listing 35: The code after some more iterations def push ( val push val def last def size def pop class NoMoreElementsException < StandardError describe Stack do before : each = Stack. new it " should be able to push one item to the top" push peek. should == "foo" it " should be able to push many items" do items = %[ foo bar baz qux ] items. each do push peek. should == item it " should be able to look at the top without removing it" push "foo" size size. should == size it " should be possible to pop the top" push "foo" size_before_pop pop. should == " size. should == size_before_pop 1 15

16 it " should NOT be possible to pop an element from an empty stack" do lambda pop }. should raise_error ( NoMoreElementsException ) Figure 5: Test output 16

17 def = [ ] Listing 36: The complete implementation def push ( val push val def last def size def pop or raise NoMoreElementsException class NoMoreElementsException < StandardError describe Stack do before : each = Stack. new it " should be able to push one item to the top" push peek. should == "foo" it " should be able to push many items" do items = %[ foo bar baz qux ] items. each do push peek. should == item it " should be able to look at the top without removing it" push "foo" size_before_peek size. should == size_before_peek it " should be possible to pop the top" push "foo" size_before_pop pop. should == " size. should == size_before_pop 1 17

18 it " should NOT be possible to pop an element from an empty stack" do lambda pop }. should raise_error ( NoMoreElementsException ) Figure 6: Test output References [1] Kent Beck. Test-Driven Development by Example. Addison Wesley [2] Scott W. Ambler Introduction to Test Driven Design (TDD) March 31, Feb 2008 [3] Dave Astels. Interview with Dave Astels and Steven Baker. Dave Astels and Steven Baker on RSpec and Behavior-Driven Development. Mar 30, Steven-Baker [4] chromatic Extreme Programming - pocket guide O Reilly 2003 [5] Dave Astels. A NEW LOOK AT TEST-DRIVEN DEVELOPMENT 18