Live data from Hacker News

Ask HN: Do you write tests before the implementation?

news.ycombinator.com

11–20 of 329 posts

Re: Ask HN: Do you write tests before the implementation?

#11

I recently started doing this. My project involved using three different services, where one of them was internal. I only had API documentation for these services and because of many reasons, there was a delay in obtaining the API keys required and I was stuck on testing my code. That's when I decided to write unit tests and mock these services wherever I am using and started testing my code. There were zero bugs in…

Thanks, an interesting perspective. Do you plan to go with this approach for your other projects as well?

I am planning to do this for my hobby projects. I think it will help me write better code and also learn a few things. For professional projects, I think the time I will try to add stuff but it relies on my manager's approval.

Re: Ask HN: Do you write tests before the implementation?

#12

Earlier quoted context omitted.

Thanks for your perspective. One issue is that it is often hard to tell in advance whether you know what you are doing or not. Also in my experience some implementation details can lead to a revision of the interface as well.

My best advice is to try it both ways (assuming you are interested in Test First/TDD). You'll find a sweet spot that works well for you. This is an area where I think there are lots of things that can work well. For me, my TDD is probably the sharpest knife in my kit, so I rely on it. For others, maybe there are other things. Don't let anyone tell you that there is only one way to do it. Of course you have to find a…

Thanks for your advise. I think it is an advantage to learn about different ways to look at a problem. Thankfully there are a lot of ways to look at problems when working in the software business.

Re: Ask HN: Do you write tests before the implementation?

#13
post #6

I mean how many of you stick with this test driven development practice consistently? I have been doing this for a while now. Practically, saves me a tonne of time and am able to ship software confidently. Can you describe the practical benefit? Say, a change is executed on one section of the (enterprise level)application. You missed addressing an associated section. This is easily identified as your test will FAIL.…

Thanks for your perspective. Did it take a lot of time to develop the required discipline? I mean defining the interface for a single function is different from defining a set of functions in the context of a test. May i ask: what is your problem domain / field of work?

Did it take a lot of time to develop the required discipline? I wouldn't say lot of time. If you get a good mentor, it isn't a steep learning curve. Moreover, I program using a framework, it has lot of helper functions.

May i ask: what is your problem domain / field of work? I develop SAAS apps and complex HA web applications/API. I am web developer - PHP(Laravel to be exact).

Re: Ask HN: Do you write tests before the implementation?

#14
> I mean how many of you stick with this test driven development practice consistently?

I do for some projects. For example currently I'm working on a project that has a high test coverage and most bugs and enhancements start first as a test and then they're implemented in code. TDD makes sense when the test code is simpler to write than the implementation code.

> Can you describe the practical benefit?

It may take some time to write initial tests but as I'm working with some legacy enterprise tech serializing all inputs and testing on that is a lot faster than testing and re-testing everything every commit on real integration servers.

Tests provide you with a safety net when you do refactors or new features so that the existing stuff is not broken.

> Do you happen to rewrite the tests completely while doing the implementation?

Yeah, I do. There are two forces at play - one of them pushes to test that cover more stuff in a black-box matter - they won't be broken as often when you're switching code inside your black-box. On the other hand if you've got finer grained test when they break it's obvious which part of code is failing.

> When does this approach work for you and when did it fail you?

It works for projects that are hard to test other way (we've got QA but I want to give them stuff that's unlikely to have bugs) and for keeping regressions at bay. It did fail me if I didn't have necessary coverage (not all cases were tested and the bug was in the untested branch).

I wouldn't also bother to test (TDD) scratch work or stuff that's clearly not on critical path (helper tools, etc.) but for enterprise projects I tend to cover as much as possible (that involves sometimes writing elaborate test suites) as working on the same bugs over and over is just too much for my business.

Re: Ask HN: Do you write tests before the implementation?

#15
Never done this, and don't consider it practical. Code and interfaces (even internal ones) change rapidly for me when I'm starting a new project or adding new major functionality to the point that the tests I'd write at the beginning would become useless pretty quickly.

I also believe that 100% test coverage (or numbers close to that) just isn't a useful goal, and is counterproductive from a maintenance perspective: test code is still code that has to be maintained in and of itself, and if it tests code that has a low risk of errors (or code where, if there are errors, those errors will bubble up to be caught by other kinds of testing), the ROI is too low for me.

After I've settled on interfaces and module boundaries, with a plausibly-working implementation, I'll start writing tests for the code with the highest risk of errors, and then work my way down as time permits. If I need to make large changes in code that doesn't yet have test coverage, and I'm worried about those changes causing regressions, I'll write some tests before making the changes.

Re: Ask HN: Do you write tests before the implementation?

#16
The majority of the time, no.

There are a couple of circumstances I often do, though.

The first is when fixing a bug - writing the (red) regression test first forces me to pin down the exact issue and adds confidence that my test works. Committing the red test and the fix to the test in two commits makes the bug and its fix easy to review.

The second is when I'm writing something high risk (particularly from a security standpoint). In this case I want to have a good idea of what I'm building before I start to make sure I've thought through all the cases, so there's less risk of rewriting all the tests later. There's also more benefit to having a thorough test suite, and I find doing that up front forces me to pin down all of the edge cases and think through all the implications before I get bogged down in the "how" too much.

Re: Ask HN: Do you write tests before the implementation?

#19
Definitely, whenever I have a clearly defined design to implement. If I don't, I generally try to design the API/interface first, then write at least the basic tests before implementing.

That being said, I never write all the possible tests before starting with the implementation. They're called unit tests for a reason -- I generally write at least a few tests for a particular unit (say, a function or method) and then write the implementation before starting working on another. And I often go back and add extra tests for an already implemented unit to cover some edge cases and error conditions.

Post reply on HN