As I know, changes in design system is happened quite frequent, even while we are coding (in fact mostly, I found better design after I code it). In test drive development, as far as I know, programmer must write test unit first, and then code.
Doesn’t that means I must rewrite all the involved unit test? If the project is a frequent change structure, is TDD a good approachment for this case? Because for me it seems like it’s consuming more time than we should do. I just in this case, it’s better writing the code first, later write the test unit (but that would be mean not TDD) Or actually are there any rules to write good test unit, so even there are changes in class structure, won’t effect the test units? Currently I haven’t thought anyway…
Smart people say that unit tests describe how can you use your components. That is, you should write unit tests as requirements to your class’s interface. This is good in theory, but in practice we often change public interface of tested class.
However, although I’m new to Yii, MVC, and OOP, I feel myself comfortable using unit testing.
@junxiong I get into this kind of situation too. When my codes are out there in the battle field, then I know what to add/change rather than when it is sitting inside the test cases.
Yeah… that’s why for a beginner in unit testing like me, it’s really consume a lot of time to code both in unit testing and coding. Since I am not a experienced in analyst system (making use case and class diagram), changes in code seems so frequent. That makes me unable to write unit test in the tight schedule project…
Maybe it’s really depend on the analyst and the programmer skill though?
That is what makes BDD so interesting, it is a different way of thinking about testing, where we test how does it behaves according to our overall business logic, rather it how does a piece of code works on a technical level.
