Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Do you write tests before the implementation?

news.ycombinator.com

Post reply on HN
Print view View original

291–300 of 329 posts

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

#291

Post by gtyras2mrs »

I don't. My approach probably isn't ideal. But I find it really hard to start with tests for new solutions.

With a basic understanding of the problem and the expected solution, I start off directly with prototype code - basically creating a barely working prototype to explore possible solutions.

When I'm convinced that I'm on the right track (design-wise), I start adding more functionality.

When I'm at a stage where the solution is passable - I then start writing tests for it. I spend some time working through tests and identifying issues with my solution.

Then I fix the solutions. And clean up the solution.

At this point my test cases should cover most (if not all) of my problem statement, edge cases and expected failures.

When it comes to maintaining the solution, I do start with test cases though. Usually just to ensure that my understanding of the bug or issues is correct. With the expected failure tests, I then work on the fix. And write up any other test cases needed to cover the work.

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

#292

Post by he0001 »

I resisted TDD at first and then became a firm believer and then dropped it to then turn around again to practice it again.

The major thing is that the tests becomes a boundary of sorts which enables you to do a lot more then if you didn’t have it. It can also be done horribly wrong which was the reason why I stopped using it.

I see it as a tool to see how good your code and abstractions are. Large tests => leaky abstraction. Many details (Mocks/stubs) in the tests => leaky abstractions.

Also it reminded me that sometimes I’m trying to satisfy the language instead of just solving the problem. As soon you are trying to satisfy your language, code style/principle or architecture, you are now trying to solve something that has nothing to do with the problem and just causes the code to be designed wrong, or that I should move it somewhere else. Though if I need to tweak the code to make it more testable, I always do that.

I also have a rule, never test data, only test functionality. This have worked very well over the years creating pretty clean code and clean tests and I believe less bugs, or at least it’s hard to be sure. Though my perception that during the periods that I switched between the practices the TDD code had less bugs and I could confirm them faster than the code which had no tests. Also the code that was produced with TDD was a lot easier to make new tests for, where the non TDD code were really hard to write tests for, if I wanted to for example confirm a bug or a feature.

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

#293

Post by stingraycharles »

seanwilson wrote: post #189
Jimpulse wrote: post #171

Earlier quoted context omitted.

Can you give a run down on formal verification?

So say you were writing a sorting algorithm and with unit tests (perhaps with TDD) you wrote tests like: - sort([]) should produce [] - sort([1]) should produce [1] - sort([1,3,2]) should produce [1,2,3] - sort([1,5,6,2,3,4]) should produce [1,2,3,4,5,6] You would test a few values and edge cases until you were confident it works for all lists. However, you can't be 100% sure that there's some list out there like [5,…

Isn’t this formal verification more for algorithms than implementations? Eg if I have to use Coq to prove my code works, what use is that for my C application? Porting the code to Coq seems to defeat the point of formal verification, I can much better use some property based testing method.

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

#294

Post by kragen »

Izkata wrote: post #273
kragen wrote: post #251

Earlier quoted context omitted.

> You're just trying things and seeing if some api gives you what you want or works as you might expect. I don't do most of my programming this way, because mostly I'm writing new things, not gluing together existing APIs with a tiny amount of simple glue code. But when I do need to characterize existing APIs, I find that unit tests are a really helpful way to do it — especially in languages without REPLs, but even i…

You appear to be talking about unit tests in general, while GP was talking about test-driven-development (what the original question is about).

Good point, thanks.

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

#295

Post by aazaa »

christophilus wrote: post #126

No. Tests are like any other code. They incur technical debt and bugs at the same rate as other code. They also introduce friction to the development process. As your test suite grows, your dev process often begins to slow down unless you apply additional work to grease the wheels, which is yet another often unmeasured cost of testing in this fashion. So, in short, I view tests as a super useful, but over-applied too…

> Anecdotally, I've worked for companies that test super heavily, and I've worked for companies that had no automated tests at all.

How did refactoring work at that latter company?

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

#297

Post by kpU8efre7r »

Unrelated but my last employer wanted a full design document and then a full test plan down to each individual unit test before we wrote any code. But then we would constantly be called out in review about not having enough detail and if you.out enough detail you'd get called out for skipping ahead in the process. They also had no coding standard or style guide to speak of. I'm glad I left that job.

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

#298

Post by kpU8efre7r »

kelnos wrote: post #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:…

I've been asked to literally test that values are incremented. Like, does ++ add 1 to the value in C, just to be safe, for the sake of 100% coverage.

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

#299

Post by jlangr »

mattmanser wrote: post #38
cygned wrote: post #33

No, in fact, we don’t use coded tests at all, deliverables are tested by the product owner(s). On the code level, we hardly see bugs, not even when refactoring. I often wonder if it is luck or expertise, and whether we would benefit from writing tests.

I used to wonder the same thing, until I inherited a project with tests. The tests never caught a bug for the first 3 years. Got in the way a lot though. Then they finally caught 1. Not worth it.

I don't see unit tests "catch bugs" often, either, in the sense that the CI build fails due to defective code pushed up.

And even with TDD, I don't often find myself breaking a lot of things that were already working, though it does happen. In those infrequent cases, it's extremely valuable to know I broke stuff that was working. I.e., it's pretty sad to ship changes that broke other behaviors, things you had the faintest clue that you were impacting.

What I do see gobs of, when doing TDD, is the tests preventing crap code from getting integrated in the first place, i.e. when I or others first write the code (or change the code of others). From the testing perspective, that's the real thing they do--gate the defects from ever leaving your desktop, and in a far faster manner than most other routes.

Unless, of course, one is a perfect coder.

In any case, TDD has more important benefits that I've also gotten. Easily worth it for me.

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

#300

Post by ragona »

tluyben2 wrote: post #66
kelnos wrote: post #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:…

That is how I used to work; then I got into finance and there are two things different with the work I did before that (web/desktop/app (or too long ago; there was no 'testing' in the 80s) the software I write now has to be certified/audited to some extent and I cannot change/repair production software on the fly. That could costs a lot of money for certain bugs. So now I tend to write tests for everything and that h…

Agreed, and the kind of software you’re working on is a part of this conversation that often gets left out and leads to people talking last each other. I work in cryptography, and our work needs an exceptionally high level of testing to catch subtle bugs. I used to work in games and I didn’t see the same value out of tests. Different industries require different practices.
Post reply on HN