4 ms·

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

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

mytailorisrich 6y ago
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...
- sys_64738 6y ago
  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.
asadkn 6y ago
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.
- sys_64738 6y ago
  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.
cheez 6y ago
God I hate this stupid industry so much
theshrike79 6y ago
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?
- eithed 6y ago
  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.
  - alecbenzer 6y ago
    Can't tell if serious...
    - sys_64738 6y ago
      They are. If you don't get it then you're doing it wrong.
    - eithed 6y ago
      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.

mytailorisrich 6y ago

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

sys_64738 6y ago
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.

asadkn 6y ago

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.

sys_64738 6y ago
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.

cheez 6y ago

God I hate this stupid industry so much

theshrike79 6y ago

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?

eithed 6y ago
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.
- alecbenzer 6y ago
  Can't tell if serious...
  - sys_64738 6y ago
    They are. If you don't get it then you're doing it wrong.
  - eithed 6y ago
    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.