It is a nice quote, but frankly I would not want that to be the takeaway. Remembering "Avoid running main" is just a principle without reasoning or justification, past remembering it sounded right when first read.

The underlying concept is that unit tests should verify behavior of minimal units of functional code. If you are running the application, you are testing much more high level functionality. "Running main" and "running unit tests" are completely different things, and I would rather the principle behind this difference be the takeaway, rather than just "avoid running main."

The advice really is to avoid the quick dopamine hit of running the app and seeing the new feature work by manual testing.

It's a motivation thing, and I think it can be very valuable tip how to motivate yourself to keep up your unit test suite (for those of us who need this behavioral trick).

yeah but we are human and flawed, at least I am. this is just a practice that forces me to properly test and be less lazy, because I can't test it manually and move on.

I don't like "avoid running main", I feel like it would undermine "holistic" engineering, since you're missing out on using the feature in the context of the application.

> However, it’s also largely-wasted effort! A manual test only verifies the current state of the code base.

I don't think this is true, at least for GUIs, because manually using the UI validates that it works for a human. An automated GUI test does really only cover a tiny, tiny subset of the interaction between the human and the machine (yes, ideally "someone else would do it", but how many companies did you work for that actually has UX reviews and dedicated UX testers? Not to speak of open source).

Also and especially for larger applications I strive to get to the dogfooding point as fast as possible, because dogfooding provides invaluable feedback, not only for GUI and UX, but also for the sort of issues that tend to get overlooked in tests and reviews, eg. leaks in long-running processes, or structures that don't scale well. Dogfooding also tends to mean that the overall structure becomes relatively stable quickly, which makes writing a comprehensive test suite easier at that point, since you don't have to constantly work on both tests and implementation, but can concentrate on either.

Writing this reply made me think that I'm probably even less of a TDD person than I thought before.

It really depends on which application. In the past few years I've been mainly writing server-side infrastructure libraries and services with no GUI at all. In those cases I'm writing stuff bottom-up anyway, so while I'm writing the bottom layers (data structures, interfaces, algorithms), I'll be testing them and playing with them with no big app wrapping them. It's both faster to write the bottom layers like that, and eventually you end up with pretty solid tests. So it's not a compromise for me in these cases.

It depends hugely on the size of your application, and of your team. For small applications and and a team size of up to three devs, your approach might be preferable. But I can't imagine that it would scale well beyond that. You will be able to test that your newly introduced feature works as expected, but you will almost certainly not be able to verify that you didn't break anything meanwhile. In general, you write tests mainly not to ensure that what you just developed works, but to ensure that it keeps working while the application evolves.

A good way to encourage modular testing over manually clicking through whatever feature you just added, is to make the "main" startup painfully slow or include manual steps other than just hitting "run" in an IDE.

If the effort of writing a few tests is smaller than actually running the application, the tests will be written because developers are lazy (instead of the other way around).

In the good old days of massive JBoss EE applications, this was taken care of automatically by the app server :)