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

141–150 of 329 posts

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

#141

Post by agentultra »

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…

Thankfully we don't have to. Hillel Wayne links to a few of the studies that have been done on TDD [0]. It doesn't have a conclusive effect on error rates in software. While I do write tests before I write code, more so in a dynamic language without a strong, static type system; it appears that there isn't any correlation to a reduced number of bugs.

But I still do it. And I think that's because that while I may prevent a few obvious errors with the practice the benefit I get is from the informal, automated specifications of the units of a module that I'm building. I also get the benefit of a continuous refactor cycle. Less experienced developers wonder how I write clean, simple code: I refactor, a lot, all the time, because I have tests checking my code.

If it's functional correctness we're after TDD is only one, small, piece of the puzzle. A strong, formal specification will go a lot further to ensuring correctness than fifty more unit tests.

[0] https://www.hillelwayne.com/talks/what-we-know-we-dont-know/

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

#142

Post by roland35 »

I mainly write embedded software and I tend to write my tests using Robot Framework. I generally start by writing the new feature since I need to probe around how it will work on the hardware, but generally write the test before the feature is actually finished. This is because the test itself will help me recreate the conditions I need the hardware to be in during debugging! One example is sending a specific sequence of serial commands over the CAN bus, or hitting a sequence of buttons on the user interface.

I am still trying to figure out the best way to do unit testing with embedded C (working with Unity right now), but with Python development I try to write unit tests only for more tricky code.

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

#143

Post by hackerm0nkey »

theshrike79 wrote: post #79

No, because I very rarely do algorithmic stuff that would benefit from unit tests. When I start to build something, I don't exactly know how it will work and what the output will be.

What code won't benefit from unit testing ?

If you don't know what to test, then you don't know what you are implementing. Find what that is, clarify it and pin it down with a test then move on to the implementation to make it happen.

If you don't know what the output is like, then do some exploratory throw-away work to know a little more. Then write the test that you would've written if you knew what the output is like.

tackle your problems one a at a time, not knowing what to test is not a good enough excuse to not test first.

Make it Work - Make it Right - Make it Fast (while still under the protection of your first-written test)

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

#144

Post by fergie »

The answer to this question depends on the type of programming you do.

1)

Working as a part of an enterprise team on a big lump of TypeScript and React? Then you probably don't write tests before you code because a) TypeScript catches all the bugs amirite? and b) Your test runner is probably too hairy to craft any tests by hand, and c) You are probably autogenerating tests _after_ writing your code, based on the output of the code you just wrote, code which may or may not actually work as intended.

2)

Working on an npm module that has pretty tightly defined behaviour and the potential to attract random updates from random people? Then you _need_ to write at least some tests ahead of time because it is the only practical way to enshrine that module's behavior. You need a way to ensure that small changes/improvements under the hood don't alter the module's API. This means less work for you in the long run, and since you are a sensible human being and therefore lazy, you will write the tests before you write the code.

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

#146

Post by kungtotte »

pubkraal wrote: post #121
pgcj_poster wrote: post #94

Yeah. I also floss every day, clean up the kitchen as I cook, keep off-site backups of my personal data, call my mother regularly to thank her for raising me, read the terms and conditions to online services, keep an up-to-date to-do list, and change all my passwords once a month.

I believed it until your password remark. That's a bad, bad practice.

Even with a password manager?

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

#147

Post by ChrisMarshallNY »

Here's what I tend to do: https://medium.com/chrismarshallny/testing-harness-vs-unit-4...

Basically, sometimes, it makes sense to write tests beforehand, but most of the time, I use test harnesses, and "simultaneous test development."

Works for me. YMMV.

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

#148

Post by apocalyptic0n3 »

I attempt to, but it often doesn't work out that way. I'd say maybe 40% of my tests are written before the implementation and I start 75% of the remaining implementations by writing tests before forgetting them and completing the implementation and writing tests for it after.

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

#149

Post by BiteCode_dev »

It depends of how much control I have over the topic. If:

- I know the topic well. - I understand the domain well. - I can picture the technology, expectations and API well. - I have the mastery of my time and deadline.

Then yes, I do.

E.G: I'm currently making a proposal for a new API in an open source python lib called iohttp.

I have time. I have leeway. I have a good overview of the entire problem. So I can afford thinking about the API first:

https://github.com/aio-libs/aiohttp/issues/4346

Then I will write unit tests. Then I will write the code.

But that's a rare case.

Many times coding involves fiddling, trying things out, writing drafts and snippets until something seems to start to solve what you want.

Other times, you want a quick and dirty script or you have a big system, but you are ok with it to fail from time to time. The cost of testing is then not worth it. You'll be surprised of how well a company can be, and how satisfied customers says they are despite the website showing a 500 once in a while.

And you course, you have limited resources and deadlines. Unit tests are an upfront payment, and you may not be able to afford it. Like it's often the case, this means the total cost of the project will likely be higher, but the initial cost will be in your range of price. And you may very well need that.

One additional things few people talk about is how organizations can make that hard for you. You may be working in orgs where the tooling you need (CI, version system, specific testing lib...) may be refused to you. You may even be working in companies where you cannot get clear information about the domain, but get a vague specs, and the only way to design the software is to ship, see it break, and wait for customers to report to you because otherwise the marketing people don't let you talk to them. I'd say change job, but it's not the point.

At last, you have the problem of the less experienced devs. TDD is hard. It requires years of practice in the field to be done properly because you build a system in a completely abstract way. Dependency injection, inversion of control, mocking and all that stuff you need to make a properly testable system is not intuitive: you learn it on the way. Even harder is the fact you have to use it in your head since your are not coding it, but what wraps it, first. And even more terrible is the fact that baldly implemented, over used and over engineered, design patterns make problem worst, not better.

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

#150

Post by ellimilial »

Yes, most of the time for the non-exploratory code that is not deeply ingrained with external framework.

When starting a new module / class I put a skeleton first, to establish an initial interface. Then I change it as I find, while writing tests, how it can be improved.

When dealing with bugs - red / green is incredibly helpful with pinpointing the conditions and pointing exactly where the fault lies.

When introducing new functionality I do most of the development as tests. Only double checking if it integrates once before committing.

Going test first pushes your code towards statelessness and immutability, nudging towards small, static blocks. As most of my work is with data, I find it to be a considerable advantage.

It provides little advantage if you already rely heavily on a well established framework that you need to hook to (e.g. testing if your repos provide right data in Spring or if Spark MRs your data correctly).

I tend to change/refactor a lot to minimise the maintenance effort in the long run. I would spend most of the time testing by hand after each iteration if not for the suite I could trust at least to some extent.

Post reply on HN