0

I saw this question: Repeating code in JUnit tests earlier today. How do you write this code when you are starting? You see that there is a method addDrivingRecord(...). This method does not exist when you first start writing so do you make that test, ensure that it works, then proceed with setUp() method, or do you instead wait until you have written the addDrivingRecord(...) method and then refactor it to the @Before? I will explain further if needed.

Community
  • 1
  • 1
user626912
  • 2,546
  • 3
  • 24
  • 33
  • So your question is "should I use addDrivingRecord in the test method / implement addDrivingRecord / ensure it works / refactor" or should I refactor addDrivingRecord first and then implement it? – helios Feb 20 '12 at 14:56
  • I'm not sure, but if your question is about methodology you could retag it as tdd (or test-driven-development). – helios Feb 20 '12 at 15:01
  • If you write a new test class, why write something when you know you are going to refactor anyways? I am not sure if I understand your question right, but whether writing a new test or just refactoring an old one, the test results should be the same. So do all the refactoring, then the testing. – steffinchen Feb 20 '12 at 15:04

1 Answers1

4

If I understood well your asking if you should:

  1. use addDrivingRecord in the test method
  2. ensure it goes green (it works)
  3. refactor addDrivingRecord to @Before

or

  1. use addDrivingRecord in the test method
  2. refactor addDrivingRecord to @Before
  3. ensure it goes green (it works)

If it's your question I should go for the first option: first use method, then implement and go green, then refactor your test.

Because two reasons:

  1. You should test/implement one thing at a time, so you will write one test method. Then you will make it green. Only then you should write another method and realize that code can be refactored in a @Before

  2. A good practice is write test methods and only when you realize there are common things move them to @Before. That way you don't enforce innecesary things in initialization. Moreover, if you find that another test needs a very different @Before method it probably belongs to another test class.

helios
  • 13,574
  • 2
  • 45
  • 55