1) That unit tests are believed to be necessary to create good software is a damning indictment of both industry and academia. Decades have been spent researching things like formal methods and static analysis and unit tests are the best we can do?
2) Having a minimum code coverage requirement leads to a bunch of tests that do little more than test the VM/runtime, not the code that's supposed to be being tested.
3) Having unit tests is nowhere near as useful for refactoring as people claim.
4) Unit testing became fashionable only because people started using Ruby on Rails and they needed to make up for the lack of static types and billable hours (1/4 of the time compared to java meant a 1/4 of the amount of pay).
I didn't say unit testing didn't exist. I said it wasn't fashionable. No one in 2005 would have been accused of not being a professional if they didn't do unit testing.
I was there too. I'm so old I remember when unit tests would have been called white box tests and looked at as an inferior form of test as you can see the code.
I can even remember being told how in the future all we would need to write is the formal spec and the computer would work out what the executable code should be. Needless to say that future never arrived.
To a very large extent I agree with this. Unit tests are a horrible replacement for a lack of static typing. That doesn't mean they aren't useful, but if you're using unit tests to prevent breakages during refactoring, do yourself a favor and just learn a freaking statically typed language.
That is, learn literally anything other than JavaScript.
You should only unit test units which are worthwhile to test. No need to test setters and getters unless they contain business logic. Requiring a minimum coverage is bad. But aiming for a minimum isn't.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
1) That unit tests are believed to be necessary to create good software is a damning indictment of both industry and academia. Decades have been spent researching things like formal methods and static analysis and unit tests are the best we can do?
2) Having a minimum code coverage requirement leads to a bunch of tests that do little more than test the VM/runtime, not the code that's supposed to be being tested.
3) Having unit tests is nowhere near as useful for refactoring as people claim.
4) Unit testing became fashionable only because people started using Ruby on Rails and they needed to make up for the lack of static types and billable hours (1/4 of the time compared to java meant a 1/4 of the amount of pay).
Unit testing was in wide use LONG before Rails.
I didn't say unit testing didn't exist. I said it wasn't fashionable. No one in 2005 would have been accused of not being a professional if they didn't do unit testing.
Having been there, I disagree, and submit that our contexts are probably different.
I was there too. I'm so old I remember when unit tests would have been called white box tests and looked at as an inferior form of test as you can see the code.
I can even remember being told how in the future all we would need to write is the formal spec and the computer would work out what the executable code should be. Needless to say that future never arrived.
You're probably doing tests wrong or I'm doing something you wouldn't call tests. That's the only logical explanation I can think.
Out of interest, what language(s) are you using?
PHP
To a very large extent I agree with this. Unit tests are a horrible replacement for a lack of static typing. That doesn't mean they aren't useful, but if you're using unit tests to prevent breakages during refactoring, do yourself a favor and just learn a freaking statically typed language.
That is, learn literally anything other than JavaScript.
You should only unit test units which are worthwhile to test. No need to test setters and getters unless they contain business logic. Requiring a minimum coverage is bad. But aiming for a minimum isn't.