Whether you do TDD or not shouldn't even be visible to others on your team, because you make the tests pass before you commit/submit/push code anyway, so whether you wrote the tests first or afterwards doesn't matter to anyone but you.
What matters to me even more than whether the tests exist is that they're readable. Far too often, tests just call methods without saying why, what they're testing or why the results are expected to be as they are. They become mere verifications that the code does what it used to do, and when mocks get involved, they even end up proving that the code has the same implementation as it currently has, which seems worse than redundant. Speaking of mocks, has anyone ever seen a readable test that uses mocks? I haven't. On Fri, Feb 21, 2014 at 3:34 PM, Fabrizio Giudici < fabrizio.giud...@tidalwave.it> wrote: > I consider myself and advocate of TDD, not a "fan" - with this I mean that > it's one of the most important best practices, but it must not be taken > with zealotry. > > Cédric wrote some very reasonable points. As usual, it depends on the > context. There are places where it makes sense to have innovative > solutions, and maybe you have to try 2/3 different approaches before to > find the good one. Being obsessive with TDD here can be a waste of time, so > I'd do some, but with more focus on getting quickly to a > validation/rejection point of the solution. Summing it up, I could say that > it makes sense to do less TDD when prototyping, even though I'd still do > some. > > OTOH in many cases, call them boring if you wish, you are in a slight > variation of something you've seen before: CRUD, reporting, alarms, etc... > Here you can safely start with more TDD. > > The most important point by Cédric, whom I agree to, is to give more > importance to integration/functional tests rather than unit tests - or, > let's say again it depends on the context, but don't go blindly with tons > of unit tests; think it over, be sure to give the proper value to the > proper categories of tests, and focus on the value. > > In the end, the very, very, very important thing is to *have tests*. I > still see tons of pains because people don't have tests and spend most of > the project time to fix regressions that could be easily avoided, or they > get stuck into legacy code without any possibility of refactor because they > don't have control because they don't have tests. You can have tests even > when you didn't go with the 100% TDD approach. OTOH, it's really easier to > write tests in TDD rather than adding later, for a number of reasons, > including that you'll have a design where tests fits better. > > Truth lies in the middle. My rough way to say it is that in the typical > contexts I see "60%-70% TDD" is the way to go - I mean, if I look at > coverage metrics in this kind of projects, the coverage in the first > iterations is 60%/70%. Then it should go up as the project stabilizes. It > would be more meaningful to measure coverage on functional points rather > than code alone. > > > -- > Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. > "We make Java work. Everywhere." > http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it > > > -- > You received this message because you are subscribed to the Google Groups > "Java Posse" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to javaposse+unsubscr...@googlegroups.com. > To post to this group, send email to javaposse@googlegroups.com. > Visit this group at http://groups.google.com/group/javaposse. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To unsubscribe from this group and stop receiving emails from it, send an email to javaposse+unsubscr...@googlegroups.com. To post to this group, send email to javaposse@googlegroups.com. Visit this group at http://groups.google.com/group/javaposse. For more options, visit https://groups.google.com/groups/opt_out.
