Comment by developer1 | Hacker News Reader

Comment by developer1 | Hacker News Reader

Parent Full thread

> few developers like to write tests

I like how this statement completely skips the reason why developers don't like to write tests. The majority of managers refuse to allocate any time to write any tests. Hell, when we come up with a 6-week estimate for a project, they then tell us we must do it in 4. At 4 weeks, the complaints and blame game begins over why the project isn't completed. Why? Because it was a 6 week project, morons.

I've only had one company with management that wanted unit tests written for code. Yet there was no official time dedicated to this process. That 6-week project that would be estimated without unit tests? Still 4 weeks. Huh? What magical world do you live in?

Quality requires time. That 6 week project now needs 8-9 weeks. Not 4. Not 5. Find me management that understands this and actually cares about quality instead of impossible deadlines that fit their fantasy plan for the current quarter, and we'll talk.

To be clear, I love writing tests. I would always have them if the decisions for project deadlines were left to me. Such decisions are out of my control, so the company gets what they are willing to pay for.

That's not the only reason. Writing tests is hard.

Writing tests that are not highly coupled to implementation is hard. That means that every time you change the system, you have one or many test changes to make too.

How do you know what to test and what not to test? How many tests do you write? One line of code can, if you think about it exhaustively, require 3 or even more tests.

A lot of time you'll write code that facilitates testing. Do you test this code? What happens if the code silently fails and now you don't have proper test coverage of all the code paths said code is supporting? This is particularly true if you are mocking objects.

Learning how to test, properly, is almost as hard as learning how to code. My advice is, if what you're doing is boring, like most Rails apps, lean on the library as much as possible, break up anything that goes against the grain into unitary features, and test them each in turn. You don't need to test that ActiveRecord.belongs_to works.

It doesn't surprise me that there's developer reticence towards testing. I tried powering through that reticence, believing there's some "magical world" as you put it, where testing actually helps you code faster and more accurately, but I found even myself a TDD apostate, I don't even do it for my own projects anymore.

I agree. Nothing is as easy as it seems. There is a whole reason why someone is hired to do QA, and why there are research in software testing.

Technically these issues are solved with what I indicated is always missing: time. What you outlined is accurate: proper testing also requires proper planning for tests. For more complicate projects, you don't just start writing them without mapping out everything that needs to be done - and how to go about it. And yes, when code changes, more time must be invested into refactoring the tests.

This disastrous ecosystem exists with QA too (which is again, a form of testing). A lot of companies - usually the smaller ones - don't invest any resources at all for QA. Others just do point-and-click smokescreen tests that'll discover bugs that are blatantly obvious (also typically the ones the developer should never have committed to begin with). Real, proper QA? That requires investing serious time into test cases - completely figuring out every possible interaction and scenario that can take place. All before a single actual test is run. And similar to unit/functional tests, QA test cases need to be reviewed whenever the smallest bit of functionality changes.

The reality is that most employers who "want test cases" want there to be a magical solution that gives all the benefits, without any effort.

If you know your estimates are going to be squeezed by two weeks, add that in and say it'll take eight.

Maybe they actually believed the many developers who told them writing tests actually saves time?

Or the employer heard what they wanted to hear.

Employer, start of project: "Oh, it'll save time? Great!" Employer, end of project: "You said it'd save time, lies!" Developer: "I specifically explained how it saves time in the long run. Not the initial implementation." Employer: "..."

Reply on news.ycombinator.com