undefined | Better HN

0 pointsmempko1y ago0 comments

Unit tests are a waste of time.

Design by Contract + system tests are a far superior technique that take less time and find more bugs.

0 comments

The last comprehensive study I read indicates that they improve internal and external code quality by 76% and 88% respectively while reducing productivity some[1]. If you have papers that indicate your claim I'd be interested in reading them or in ones that refute the metastudy linked below.

1. https://doi.org/10.1016/j.infsof.2016.02.004

nkozyra1y ago

TDD and using unit tests are not the same thing, though.

I'm very much a TDD sceptic, but believe unit tests have a place.

dataflow1y ago

Confused, how do you ensure that a change to your implementation of some function isn't going to break clients after deployment if you don't have a unit test?

mempkoOP1y ago

The client doesn't run your unit tests, but will run you contracts (because contracts deploy with you software while unit tests dont).

You might have realized users of software do things the engineers don't expect, which are not covered in unit tests.

dataflow1y ago

> The client doesn't run your unit tests

That's kinda the whole point... you run them to catch bugs and fix them so your clients never see the bugs you caught in the first place.

> but will run you contracts (because contracts deploy with you software while unit tests dont).

So you'd prefer your contracts to blow up your bugs in your clients' faces, rather than catch bugs yourself prior to releasing the code to them?!

1 more reply

sitkack1y ago

Unit tests are only worthwhile when your internal machinery is part of the contract.

dclowd99011y ago

How do you know the contracts are being followed?

rocqua1y ago

Either through assertions, through fuzz testing, or by formal verification.

dclowd99011y ago

Maybe I’m confused on the jargon here, but aren’t unit tests assertions?

1 more reply

_0ffh1y ago

Assertions?

dataflow1y ago

But assertions only tell you you broke someone after the fact (and only if they're enabled)? They don't do anything to help prevent you from breaking them in the first place.

3 more replies

j / k navigate · click thread line to collapse

0 comments

jackcviers31y ago

1. https://doi.org/10.1016/j.infsof.2016.02.004

nkozyra1y ago

TDD and using unit tests are not the same thing, though.

I'm very much a TDD sceptic, but believe unit tests have a place.

dataflow1y ago

Confused, how do you ensure that a change to your implementation of some function isn't going to break clients after deployment if you don't have a unit test?

mempkoOP1y ago

The client doesn't run your unit tests, but will run you contracts (because contracts deploy with you software while unit tests dont).

You might have realized users of software do things the engineers don't expect, which are not covered in unit tests.

dataflow1y ago

> The client doesn't run your unit tests

That's kinda the whole point... you run them to catch bugs and fix them so your clients never see the bugs you caught in the first place.

> but will run you contracts (because contracts deploy with you software while unit tests dont).

So you'd prefer your contracts to blow up your bugs in your clients' faces, rather than catch bugs yourself prior to releasing the code to them?!

1 more reply

sitkack1y ago

Unit tests are only worthwhile when your internal machinery is part of the contract.

dclowd99011y ago

How do you know the contracts are being followed?

rocqua1y ago

Either through assertions, through fuzz testing, or by formal verification.

dclowd99011y ago

Maybe I’m confused on the jargon here, but aren’t unit tests assertions?

1 more reply

_0ffh1y ago

Assertions?

dataflow1y ago

But assertions only tell you you broke someone after the fact (and only if they're enabled)? They don't do anything to help prevent you from breaking them in the first place.

3 more replies

j / k navigate · click thread line to collapse