3 ms·
This strikes a few chords with me from my days of managing sub-par developers. I got to the point on my projects where I prefer not-so-good code with tests over
by bradgessler 18y ago
This strikes a few chords with me from my days of managing sub-par developers. I got to the point on my projects where I prefer not-so-good code with tests over good code with no tests! Blech X-|
Great points about the people barriers to testing -- too high of a learning curve and the difficulty of finding the balance where developers are not over-testing their code.
Unfortunately I think judgment for writing good, non-fragile tests comes from a lot of experience.
- wastedbrains 18y agoI agree testing has a big learning curve. I have been doing it for years now and still find there is a lot to learn. It took a long time to make me realize how much better isolated tests were at the unit level. I think some of the language changes he suggests are interesting. Kind of follows some of the BDD over TDD. Something 'should' do something, not test. Tests should be isolated, not have objects mocked...
- jwilliams 18y agoYeah... It does come down to experience. I've found that most sufficiently large projects require a large amount of scaffolding - on a massive project, you can't write a bit of code and compile and run everything on day one, you need to put in place structures and stubs and mocks to get you going. The reality is - All of this, really, ends up being good test code. Rather than create all this throwaway code, you can actually do better by making these tests and stubs. So, a lot of developers are writing a lot of the foundations of a their testing framework and not realising it.