Hi Peter,

thanks for an extensive reply! I’ll first comment some parts of your reply and then things in general.

I think this test even failed because I was not returning a value in write(), so just some random bool was returned which happened to be false :-) I’ve even had tests that crash because no value is actually returned and a QByteArray was supposed to be returned – also a kind of red bar :-)

Hehe :).

Short comment about black-box and white-box tests. I’ve been thinking a lot about that! I try to come up with the black-box tests first. If you think about it you don’t have much choice actually as your initial implementation is mostly fake. I also think that for quite a long time I had a misconception about what white-box tests actually are. I used to think that white-box tests are ones you write after studying the implementation. One problem with that thinking is that if you think about the tests while looking at the code you are likely to write tests that pass but should have failed – that is because you wrote tests “derived” from a faulty implementation. My understanding now is that one should try to write an extensive suite of black-box tests consisting of at least one test for each usage scenario. Then, white-box testing could be used to choose more tests for each of the usage scenarios in order to achieve a better test coverage. I think that white-box tests are more about coverage (inputs producing a certain flow through the implementation and the expected output), whereas black-box tests are more about the usage scenarios.

I agree. I like black-box tests because they test a function/class in general (usage scenarios). They allow one to test changes (made when refactoring the original code) in an independant way - white-box tests can become useless if one changes the implementation. But I also regard their importance. We were once writing an intepreter of a simple imperative language as our team school project. I was writing the parsing part and my friend a symbol table. When I was writing tests (we used only “part tests”, like scanner/parser/interpreter and regression testing - we had about 200 testing examples) I didn’t look into his code to write some white-box tests, so I just made black-box tests. There was finally an “off-by-one” error in the functions parameters storage. There was a constant equal to 10 and problem appeared only when one tried to declare a function with 10 or more parameters. I made tests that were testing functions with 0,1,2,4,8 parameters because I thought that 8 it will be enough :). In situations like this, the white-box tests can be really valuable.

Btw, could you point to locations in the Introduction to TDD developer manual where you think some more information/clarification would be helpful? For example, places where you had questions which were never answered.

There were actually two things that I was missing. First thing was an example - I really like examples, because one can see how it works and doesn’t have to only imagine how it might work. I liked the example you wrote in the reply, so maybe you can extend it a little bit (but not necessarily, I think that the main idea can be seen from it) and put it into the TDD developer manual?

The second thing is the second phase (”green”). As I wrote in my previous post, I was wondering why I should just fake an implementation to make a test pass instead of write the whole code. After I read that article, I saw that this is for two reasons (correct me if I understand it wrong):

• tests the test, so one can be sure that it’s testing what it should test
• make small steps, so you can “revert” when something will go wrong

I know that it’s written there (not exactly in the same way, though), but I just didn’t manage to get these thing together when I was reading the TDD developer manual.

The rest is more or less clear to me - your reply helped me a lot. I’m going to read the Test Driven Development: By Example by Kent Beck (I saw that it’s actually in our faculty library) to gain more knowledge about it, because I like it. I know that I’ll need experience and practice, but that’s ok - I like learning things.

Anyway, thanks for that article - I finally manage to read something more about TDD!

Petr

Btw, excuse me if I’ve written somewhere TTD instead of TDD - I think I spent too much time with TTD when I was attending a high school :).