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

I have been trying to stick to the TDD approach. So I have made some tests an开发者_开发问答d 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 have implemented the observer pattern and all that happens is that I notify all the registered observers. So use a for each loop and call notify. This certainly sounds too simple to break. Now that I have the tests in places should I delete them? This also seems to be a bit of a waste of time. So should I try and anticipate methods that would be too simple to break?

No.

The methods may be too simple to break right now, but that doesn't mean they'll never need to be modified (and possibly broken) in the future.

Yes; If you're testing the functionality of the underlying compiler/virtual machine, your test is too simple. Unless, that is, you do not trust that particular piece of the compiler/virtual machine that is being exercised.

But, of course, the reality of tests is a bit more complex than just a yes/no answer to this question. As noted in another answer, if you have already written the tests, don't delete them. But you also should not use them in a code coverage context as an argument for confidence.

You're saying this is too simple to fail:

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

It's tempting to think that, 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 maybe observers aren't getting added correctly. Or...or...or...

If you already have the tests, it seems unnecessary to remove them, and one axiom of software is the functions tend to grow over time, so what's simple now may be less so down-the-line -- exactly the kind of thing your tests are supposed to help you with.

No.

You're doing it exactly right: writing tests that fail first, then fixing them. Leave those tests alone, write more complex ones in the future if you think you will need them (eg to reproduce bugs).

The more tests you have, the less pain you're gonna have in the future. Nevermind their simplicity.

Now that you've gotten all those tests to pass leave them alone. If they're running quickly enough they won't be a burden to anyone.

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

When you had all your tests failing and no implementation you had fixed your design and now its working you may be loathed to refactor the design to improve it.

I also suspect that you had a tricky time implementing your code as each implementation step might have broken more tests than it passed, but hey, I'm only guessing!