Comment by dfabulich | Hacker News Reader

Comment by dfabulich | Hacker News Reader

Parent Full thread

"For every complex problem there is an answer that is clear, simple, and wrong." -- H. L. Mencken

The saddest thing about articles like these is that they are so full of wisdom, but they can never seem to compete with the "hot new methodology."

Like it or not, the "agile" movement had a huge impact on the way people do their jobs, in part because it had a name, it had advocates, and it had principles that you could fit on a PowerPoint slide.

But good testing (like good design) just can't be encapsulated in a handful of principles you can teach to a newbie. Good testing requires wisdom.

I can write a lot of words about what I've learned about testing over the years, but it probably won't do a good job of conveying that wisdom to others. The best testers I've ever worked with have a strong gut instinct, developed by experience, for where the bugs will be found, and how to effectively spend our limited time-budget for tests.

Is it worth adding more end-to-end UI tests? What if they run slowly? (How slowly?) Is it better to add more unit tests? What if adding unit tests requires aggressively mocking out dependencies? Which parts of the product require more testing, and which ones have been adequately tested?

These questions don't have quick, easy answers, but the quick, easy answers keep winning mindshare, and we're all impoverished as a result.

Well said. But wisdom goes hand to hand with dedication. Let me paraphrase someone wiser than me:

"Dedication brings wisdom; lack of dedication leaves ignorance. Know what leads you forward and what holds you back and choose the path that leads to wisdom."

> Good testing requires wisdom.

I don’t disagree, but I’d be willing to settle for diligence and discipline.

Writing an article claiming that "it's complex" and "it depends" is the easiest thing in the world; even when these claims are false, few will dare call them out as false.

In my experience good testing actually doesn't require wisdom, or at least there's a lot more value in quick easy principles than there is in wisdom (which is very hard to assess whether it's actually achieving anything).

We have plenty of articles that pontificate and cover everything in shades of grey; actually committing to a stance and giving concrete, actionable advice (that may be wrong for occasional edge cases) is far more valuable.

(To answer your questions: have half an hour's worth of tests, start with purely end-to-end UI tests and convert cases to more unitlike tests as necessary to keep that half hour runtime. Don't ever mock, stub if you must but only after you've tried improving the code so that you don't have to. You already know which parts require more testing and which have been adequately tested, give yourself permission to trust your instincts on that one)

Half an hour is 30 times longer than I want to wait for good quality feedback.

I’ll settle for under 5 minutes, but I always shoot for 1 minute.

30 minutes is not really compatible with continuous deployment approaches

IMO a deployment that doesn't contain a user-facing feature is meaningless - so rather than being able to deploy literally every second, you only need to be able to deploy fast enough to make each user-facing feature (which is probably, what, 1/week/developer?) its own deployment. So assuming you have the kind of team size that I think is right (which is a whole other discussion), half an hour is good enough. (I'd still call that continuous deployment, because master is continuously deployed - but you only have feature branches landing in master at a rate of one per 30 minutes).

Your test-edit cycle should definitely be much shorter than half an hour, but you don't need to run the full test suite for that.

Reply on news.ycombinator.com