Hacker News Reader

Comment by mytailorisrich | Hacker News Reader

Unit tests are very important and very cheap. They safe a huge amount of grief later on.

As for everything, the pros and cons should be weighted to reach a practical and effective approach. For example there is rarely a need to test every single function.

Overall, I don't find this piece very insightful.

View on HN

> For example there is rarely a need to test every single function.

And that's where the bugs end of being.

People suck at writing code so it needs to be reviewed by peers and thoroughly tested. If you said that in an interview for code you'd written then I'd point to the door.

It's always a question of balance and return of investment. It's good to aim for 100% coverage, but it's a diminishing return exercise and it may not be particularly valuable to reach it, so in practice it usually remains an aim.

> If you said that in an interview for code you'd written then I'd point to the door.

That's an extremely arrogant thing to say. Any experienced dev will understand my point, so...

Most programmers are arrogant and that's why they write terrible code full of bugs. I posted elsewhere that if your code isn't tested then it's broken. It was sitting at negative four when I last looked. That comment should be in the hundreds. If folk don't understand that then they need to look into their software development practices.

Typical 100% coverage metric vanity with usually no real world benefits.

> If you said that in an interview for code you'd written then I'd point to the door.

And they would be better off not having to work at a place with an intolerable environment of the kind.

You aim for maximizing code paths in the minimum test cases. Test cases written correctly can be quickly reused with different input values. Design to test. Prove your code through automated unit testing. Skipping proper test development leads to terrible tech debt when you try to maintain the code. Error paths are generally the place that doesn't get most coverage and those are where you crash a lot of programs. This stuff is elementary.

God I hate this stupid industry so much

So you would write test cases for all the methods and constructors for a class like this:

  class Foo{
    public Foo(initialValue) {
        this.value = initialValue
    }
  
    public setValue(value) {
        this.value = value
    }
  
    public getValue() {
        return this.value;
    }
  }

What's the point, what are you testing? That the language's most basic operations still work?

You'd test those cases. This way, if you'll change your code to be

``` public setValue(value) { this.value = value + 5 } ```

then your tests will start to fail.

Treat tests as a contract.

Can't tell if serious...

They are. If you don't get it then you're doing it wrong.

I'm serious. Of course you don't test that language operations work, but you're testing that given method does what it's supposed to do. In this case your method sets value for property on model. It doesn't matter you're doing it via assignment - you could be doing it by any other ways. You want to test that for given model after calling that method your models property will change to given value. This way, if you'll change the implementation of setValue your test will still succeed. If it'll start doing something else, they will fail. And of course, this method can be used in your feature tests, so those will start failing too (but that's beside the point, I guess)

Of course it's also a balancing act - should you immediately write test for this? I try to.

They are cheap per unit, but if you test a lot of units, it adds up.

There is a set of bugs that only higher-level testing will catch. There is another set of bugs that both higher and unit-level testing will catch. Then there is the set that only unit-level testing will catch.

How important is that last set? If a unit test fails and there is no user interaction to trigger that failure, is it really a bug?

Unit tests can be valuable if they help you during development of a unit, but most units are not that complex and should not require unit tests.

Cost includes the impact on further tests and maintenance.

The cost of testing and debugging increases as you go down the development/release cycle.

If you have unit tests then that helps integration tests (less issues, easier to investigate), system tests, etc. all the way down to dealing with bug reports from the field.

> but most units are not that complex and should not require unit tests.

That is a very bold claim...

> If you have unit tests then that helps integration tests (less issues, easier to investigate), system tests, etc. all the way down to dealing with bug reports from the field.

Not in my experience. I don't see how a unit tests helps me with bugs that show up in the field. If it shows up in the field, something should've caught it, which means testing failed.

> That is a very bold claim...

I'm a bold guy.

Reply on news.ycombinator.com