Hacker News Reader

Comment by sys_64738 | Hacker News Reader

> 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.

View on HN

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.

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.

God I hate this stupid industry so much

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.

Reply on news.ycombinator.com