The Big TDD Misunderstanding

[viraptor]

It's nice that this reminder surfaces from time to time. Hopefully there are a few lucky 1/10000ths today.

I'd just add some nuance to:

> If you cannot reach the untested lines with the public interface of your software, maybe you can just delete those lines. Do not reach for stubs/mocks to achieve 100% test coverage, try to find a scenario of how to run through these branches by using the API from a realistic point of view.

Sometimes you need a few mocks for exceptional situations. You're not going to fill up your disk just to check that ENOSPC, or try to race the test with bringing down an interface to reproduce network timeouts.

[WolfOliver]

That is a valid point. This is exactly when you should use a mock.

[somewhereoutth]

I would add that human interfaces need to be tested by humans (preferably not your paying customers), machine interfaces by machines.

[whynotmaybe]

If the framework you're using allows for ui testing, you must use it.

For example in flutter, you can check whether a component is visible on the "screen" and simulate an action with it.

No need to ask a human to test the new ui if you can detect that the new button isn't visible on the "screen" .

Then once you know what's supposed to be there is there, a human must test it.

[MoreQARespect]

This is all good advice.

[andrewstuart]

Hopefully AI has killed TDD dead dead dead.

TDD is one of the worst concepts ever concocted by the software industry right up there with UML.

It’s all very ThoughtWorks.

One of the very best things to come out of AI development is the extent to which it sends TDD to the ninth level of hell.

[UK-Al05]

The best AI workflows works heavily with tests at the moment. Having tests up front means the Ai knows its failed, and attempts to fix it.