Live data from Hacker News

Ask HN: Do you write tests before the implementation?

news.ycombinator.com

41–50 of 329 posts

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

#41
I don't write as many tests as I'd like in general (adding tests to a legacy project that has none is a struggle - often worth it, but needs to be proitized against other tasks).

I once had to write an integration for a "soap" web service that was... Special. Apparently it was implemented in php (judging by the url), by hand (judging by the.. "special" features) - and likely born as a refractor of a back-end for a flash app (judging by the fact that they had a flash app).

By trial and error (and with help of the extensive, if not entirely accurate, documentation) via soapui and curl - i discovered that it expected the soap xml message inside a comment inside an xml soap message (which is interesting as there are some characters that are illegal inside xml comments.. And apparently they did parse these nested messages with a real xml library, I'm guessing libxml.) I also discovered that the Api was sensitive to the order of elements in the inner xml message..

Thankfully I managed to conjure up some valid post bodies (along with the crazy replies the service provided, needed to test an entire "dialog") - and could test against these - as I had to implement half of a broken soap library on top of an xml library and raw post/get due to the quirks.

At any rate, I don't think I'd ever got that done/working if I couldn't do tests first.

Obviously the proper fix would've been to send a tactical team to hunt down the original developers and just say no to the client...

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

#42

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?

More fun is when you get an API documentation and no access to the actual system. You develop the whole thing and then fly out to their site, you've got 3 days to get your software and hardware certified by them, and the certification costs a fortune.

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

#43
No. And also 'do you write a test for everything?'. Also No.

Tried it, ended up with too many tests. Quelle surprise. There is a time/money/cognitive cost to writing all those tests, they bring some benefit but usually not enough to cover the costs.

I'm also going off the 'architect everything into a million pieces to make unit testing "easier"' approach.

I heard someone saying that if you write a test and it never fails, you've wasted your time. I think thats quite an interesting viewpoint.

Reminded of:

"Do programmers have any specific superstitions?"

"Yeah, but we call them best practices."

https://twitter.com/dbgrandi/status/508329463990734848

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

#44
post #21

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 securi…

> Committing the red test and the fix to the test in two commits makes the bug and its fix easy to review. I've done this in the past. Then I started to use `git bisect` and having a red test somewhere in your commit-history is a killer for bisect. So now I tend to include both, the test and the bug-fix, within one commit.

A tip I learned is to commit the failing test but mark it as an expected failure, if your test framework supports that.

That way you can commit the test, bisect works, and the test begins "failing" when the bug is really fixed, and you can commit the fix as well as a one-line change to amend the test from being failure-expected to just a normal test.

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

#46

No. And also 'do you write a test for everything?'. Also No. Tried it, ended up with too many tests. Quelle surprise. There is a time/money/cognitive cost to writing all those tests, they bring some benefit but usually not enough to cover the costs. I'm also going off the 'architect everything into a million pieces to make unit testing "easier"' approach. I heard someone saying that if you write a test and it never f…

>No. And also 'do you write a test for everything?'. Also No.

Same here and for the same reasons plus stuff in the backlog that takes more priority; At least on Finance, gambling and telecom industries that I've worked on

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

#48
No. Most of the time I don't really have any spec to base hypothetical tests on, and I have to be exploring what is even possible as I go. When I'm throwing things at a third-party API or service to see what sticks, writing tests first is wasteful.

If I'm doing something that is pretty well defined and essentially functional, where I know the inputs and outputs, I'll sometimes do the TDD loop. It can be good for smoking out edge cases; although unless you start dtifting into brute force fuzzing or property-based testing you still have to have the intuitions about what kind of tests would highlight bugs.

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

#50
Whenever I can and it makes sense, yes. When I write a test first the resulting code is always better.

Sometimes the change is so trivial or type safe that it's not worth it, so I don't.

Sometimes I don't understand the problem well enough, so I learn more about it by doing some exploratory coding and prototyping. I usually come back and write a test after the fact.

Sometimes the project is on fire and I'm just throwing mud a the wall to see what sticks.

Post reply on HN