Well, for starters, I am just beginning to get a feel of the TDD and while I agree with sentiment that Uncle Bob et al. who promote very dogmatic approach to TDD, sometimes are a bit overzelaous with their statements to the point of impractical, there is a lot of truth in it as well.
>From my experience, I have certainly noticed, that sometimes having lots of trivial unit tests can actually make it much harder to properly refactor your code. But I would argue that it is not the tests (or more generally TDD) that are at fault but the general focus of the tests -- most likely you are testing a wrong abstraction. It takes experience to be good at anything, and sometimes, you just need to make the mistakes to get that experience. Making mistakes is always frustrating and sometimes you can not afford the time, when coding for production. This is why I have just recently found a good tool to let you learn good habits of programming in form of "Coding Dojos" and other similar types of coding exercises. If you are unsure in TDD, do not just jump in to the deep end in your production environment. First gathering some basic experience in a safe and controlled environment can help you to see the "light at the end of the tunnel". Finally, it is always about making a judgement call about what when and how to test. And test you must - if for nothing else then for the sake of being a professional and delivering a high quality product. teisipäev, 25. veebruar 2014 20:31.02 UTC+2 kirjutas phil swenson: > > well put! I agree with everything you wrote, with the possible exception > of your point on functional vs unit tests. > > 1) Writing functional tests only leads to a very slow test suite (clean > db, startup server, etc) > 2) unit tests help you write better code. code that can be swapped > out/mocked, state passed in, single responsibility stuff, etc. Unit tests > force devs to think about how the code will be interacted with and edge > cases. > 3) writing functional tests tends to happen much later in the cycle, which > means it’s harder to do mocks and stubs to get around lousy code issues as > described in point #2. And in my experience, devs don’t end up mocking > things out which leads to point #1 > > > I think the Test Pyramid is the best way to think about these things: > > http://martinfowler.com/bliki/TestPyramid.html > > I’m not arguing that we shouldn’t do functional tests, I’m just saying I > think we need the full test stack and Unit Tests are very important. > > > > > On Fri, Feb 21, 2014 at 2:47 PM, Cédric Beust ♔ <ced...@beust.com<javascript:> > > wrote: > >> Not a big fan for multiple reasons: >> >> - TDD introduces a lot of churn, especially in the early phases of your >> coding. If you're beginning to work on a problem from scratch, you will >> most likely throw one or two initial implementations before reaching >> something you feel is acceptable as a v1.0. Writing tests for any version >> prior to this one is a waste of time. >> >> - TDD encourages myopic design. You are more focused on writing your code >> so it can pass trivial unit tests than thinking about how your overall >> design will fit with the rest of the code base. >> >> - TDD has high friction. If you are very zealous with TDD, every minor >> change in the code base will cause you to update tests. I'm okay with a >> little bit of that (it's the purpose of tests) but not to the extent that >> TDD promotes. >> >> - It overly privileges unit tests over functional tests, and my default >> position is that functional tests are more important (if I have the time to >> write a functional or a unit test and just one, I'll always go for >> functional because these tests have a direct impact on users, as opposed to >> unit tests which are just a convenience for you, the developer). >> >> I have more (I wrote a bit of that in my book) but heading out for now. >> >> -- >> Cédric >> >> >> -- >> Cédric >> >> >> >> On Fri, Feb 21, 2014 at 1:08 PM, Rakesh <rakesh.m...@gmail.com<javascript:> >> > wrote: >> >>> Hi, >>> >>> **usual disclaimer about not looking to start a flame war** >>> >>> A friend of mine recently interviewed at a company for a position as an >>> iOS dev. >>> >>> The topic of TDD came up and my friend stated that she was a big fan. >>> >>> The interviewer on the other hand, said he wasn't and that the 'jury was >>> still out'. >>> >>> I'm curious, who is the 'jury'? >>> >>> As for myself, if i can join a team doing tdd or be in a position where >>> i can, i'm happy. >>> >>> This group is stocked with experienced devs so i'm not looking to >>> convert anyone, but surely by now, the nay sayers are in the decline? >>> >>> Thoughts? >>> >>> Rakesh >>> >>> Ps kevin, REALLY interested in your opinion. >>> >>> -- >>> 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+...@googlegroups.com <javascript:>. >>> To post to this group, send email to java...@googlegroups.com<javascript:> >>> . >>> 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+...@googlegroups.com <javascript:>. >> To post to this group, send email to java...@googlegroups.com<javascript:> >> . >> 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.
