3 ms·

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 ap

by dom0 10y ago

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.

dvirsky 10y ago
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.
wsy 10y ago
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.

by dom0 10y ago

dvirsky 10y ago

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.

wsy 10y ago

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.