|
|
|
|
|
|
by jeremyjh
4614 days ago
|
|
|
>I know which way is more productive for me. How do you know this? It frankly doesn't sound like you have worked on an application of similar scope that has good test coverage. I went the first decade of my career without writing tests and said the exact same things you are saying. I do agree that learning how to write effective tests is difficult and that you cannot do it by reading the web tutorials and the scant coverage given in most books. I learned how by working on an existing project with good coverage. On my own personal projects what I began doing was writing tests instead of writing most of the exploratory code in the REPL, or instead of writing a stub of a template to test some new code in the browser. I took all that ad-hoc scaffolding that naturally pops up and just structured a little bit and called that my tests. My tests are more integration tests ... I still do not understand the compulsion for low-level unit tests that do nothing other than prove the underlying framework works correctly. |
|
|
Because I have on numerous occasions tried to get tests set up, and every time another feature request / data model change comes up before I get anywhere close to building all the related objects required for the tests I want to run. (I agree it is integration tests I need rather than low level stuff that proves the framework works as expected).
The majority of the bugs I see I would not have written a test for anyway, as they are usually subtle interactions between the objects and a variation that were not anticipated in the feature request.
The design is constantly changing, as I work for a DNA sequencing centre and the technology is constantly advancing. A few bugs would have been caught by automatic testing, but not so many considering the time it seems to take me to get them put together.
It is different working for a big corporate entity that has the resources to devote to these things, but in our case we don't.