After read some articles and the sample chapters of Test Driven by Lasse, I make my mind to start my firt TDD journey. I'm doing the Test-First-Challenge on XP123. And I encounter problems as expected.
The first test case
In order to let this test compiles successfully, I create Sheet.java
Yes. It compiles ok now. But the bar is red, I have to make some changes to get the test pass.
Green! Now let's move to the next test
At first I have to make my test compiles ok, so switch to Sheet.java and add a put(String cell, String value) method
OK. Now chang the code to let the test pass. The cell-value pairs make me think using a Map to store the data. Sheet.java changes to...
Ok, run the test again. Woops! The second test fails. Ahah, the get() method needs to be changed now.
Problems occur here. The code above fix the second test, but breaks the first one. My questions are:
1 Is the rhythm ok so far?
2 It seems it's common to break the previous tests, isn't it? What do you do then?
Please don't tell me the answer how to fix the tests. I'm just not confident with the rhythm. Thanks.
Originally posted by Louis Wang: Problems occur here. The code above fix the second test, but breaks the first one. My questions are:
1 Is the rhythm ok so far?
The rhythm you're exhibiting is ok. You're taking very small steps, which is good. Over time, you'll probably start taking slightly bigger and bigger steps. Until you crash and burn. Then you remember how valuable it is to proceed in small steps and start taking smaller steps. And then the cycle continues.
Originally posted by Louis Wang: 2 It seems it's common to break the previous tests, isn't it? What do you do then?
Well, the idea is to get all tests passing in the "code" step of "test-code-refactor". If you find that it's too difficult, you need to revert back to a working state and refactor the code base such that the change is easier to make or simply take a smaller step.
It is good to have a interface driven approach. What I mean is get your interfaces (i.e. contract) defined. Start with a very simple rudimentary class design, focussing on the interfaces satisfying your requirements.
Second step would be to start writing test methods, parallely with implementation or concrete classes.
Then you should adopt the cycle of test-break-code(i.e.fix)-refactor
Decide on the optimum time you spend on the class design (not focussing too much on details initially). This gives a head start with lot of clarity in development.
Just my thoughts..might not be the best way
You can't wake a person who is <b><i>pretending</i></b> to be asleep.<br />Like what <b>"it"</b> does not like - <i> Gurdjieff </i>
Joined: Jan 28, 2005
Thank you for your replies.
Finnaly, I've finished part 1. Yes, I refactor the code to get all the tests passed.
The third test passes even no modifications to my code. As for fourth and fifth test, I'm not sure if I understand the tests clearly. So I implement the Sheet.java in a way I'm not satisfied with. But it gets all the tests passed.
Have someone else done this exercise before? I'm not confident with the implementation, although it gets all the tests passed.