Geek Answers Handbook

Should we remove tests that are too easy to break during TDD

I am trying to stick with the TDD approach. So I did some tests, and they all fail. Now I am implementing. But now that I am implementing, I have seen that the methods are too simple to fail. In particular, I implemented the observer scheme, and all that happens is that I notify all registered observers. Therefore, use for each cycle and call a notification. It certainly sounds too easy to break. Now that I have tests in places, should I delete them? It also seems like a waste of time. So should I try and anticipate methods that are too easy to break?

+6
design-patterns unit-testing tdd
source share
6 answers

Not.

The methods may be too simple to break right now, but that does not mean that they will not need to be modified (and possibly damaged) in the future.

+7
source share

Yes; If you are testing the functionality of a basic compiler / virtual machine, your test is too simple. If, that is, you do not trust that part of the used compiler / virtual machine.

But, of course, the reality of the tests is a little more complicated than just a yes / no answer to this question. As noted in another answer, if you have already written tests, do not delete them. But you should also not use them in the context of code coverage as an argument of trust.

+4
source share

You say it is too easy to fail:

for (i = 0; i < observers.length; ++i) { // Notify observer observers[i] }

It is tempting to think about it, but consider this common mistake:

 for (i = 0; i <= observers.length; ++i) { // Notify observer observers[i] }

Or this one:

 for (i = 0; i < observers.length; ++j) { // Notify observer observers[i] }

Or perhaps observers are not added correctly. Or ... or ... or ...

If you already have tests, it seems that there is no need to delete them, and one axiom of software is functions that grow over time, so now simple things may be less so straightforward that your tests should help you.

+3
source share

Not.

You do it for sure: first record the tests, and then commit them. Leave these tests alone, write more difficult ones in the future, if you think that they will need them (for example, to reproduce errors).

+2
source share

The more tests you have, the less pain you will have in the future. Never mind their simplicity.

+2
source share

Now that you have completed all these tests, leave them alone. If they work fast enough, they will not become a burden for someone.

However, in the future you may need to write only one failed test at a time. (See Three Rules ). This is because it will improve your design while you are developing your code.

When you had all the failed tests and there was no implementation, you corrected your design, and now its work can be disgusting to reorganize the design to improve it.

I also suspect that you had a difficult time implementing your code, since each implementation step could break more tests than it passed, but hey, I only guess!

0
source share

More articles:


All Articles