There's a great set of recorded hangouts between Kent Beck, Martin Fowler, and DHH titled "Is TDD dead?": http://martinfowler.com/articles/is-tdd-dead/ As with that talk, I'd highly encourage you to take the time to watch them. –Sam On Wed, Apr 1, 2015 at 6:07 PM, Corey Floyd <cfloyd(a)wikimedia.org> wrote:

Thanks so much for sharing. That series was a long haul but I found it really insightful, definitely time well spent. A few lessons I took away from it: - TDD is just one of many ways to get continuous feedback on your code. If it doesn't fit the use case, don't force it. - If you're trying out TDD, don't get too hung up on the "driven" aspect of it. It doesn't strictly mean red/green/refactor. - Don't trip on % coverage. - Tests are just as subjectively written as the rest of your code. Don't test yourself into a false bubble, a tautological hellscape of antipatterns (however you want to put it :). On Wed, Apr 1, 2015 at 12:43 PM, Brian Gerstle <bgerstle(a)wikimedia.org> wrote: -- Dan Duvall Automation Engineer Wikimedia Foundation

I mostly agree with that but I do find clarity and DRY at odds sometimes and, despite a strong desire to not repeat myself in production code, I often favor clarity in tests. One recent example where I _didn't_ make this sacrifice but I probably should have, is in the settings spec for MW-Vagrant.[1] There's some context there that says essentially "when I ask for a setting that doesn't exist, the result should be 'nil'." However, it's difficult to make the connection that the setting `:bar` is indeed missing from the definitions without going 200 lines up to the top of the file. It's possible that a better name for the key would have cleared up the intent, but an even clearer alternative would involve reiterating the initial state of `definitions` closer to the different contexts within `Settings#setting`. [1] http://git.wikimedia.org/blob/mediawiki%2Fvagrant.git/b428a620b4b30631b7925… On Thu, Apr 2, 2015 at 2:00 PM, Brian Gerstle <bgerstle(a)wikimedia.org> wrote: >> - Don't trip on % coverage. > > > A good analogy I've heard is that code coverage is to project health as > blood pressure is to human health. Bad blood pressure is usually a bad sign, > but good blood pressure isn't in itself a bill of good health. > > > > On Thu, Apr 2, 2015 at 4:44 PM, Dan Duvall <dduvall(a)wikimedia.org> wrote: >> >> Thanks so much for sharing. That series was a long haul but I found it >> really insightful, definitely time well spent. >> >> A few lessons I took away from it: >> - TDD is just one of many ways to get continuous feedback on your >> code. If it doesn't fit the use case, don't force it. >> - If you're trying out TDD, don't get too hung up on the "driven" >> aspect of it. It doesn't strictly mean red/green/refactor. >> - Don't trip on % coverage. >> - Tests are just as subjectively written as the rest of your code. >> Don't test yourself into a false bubble, a tautological hellscape of >> antipatterns (however you want to put it :). >> >> On Wed, Apr 1, 2015 at 12:43 PM, Brian Gerstle <bgerstle(a)wikimedia.org> >> wrote: >> > +1 for the follow-up of the "Is TDD Dead?" >> > >> > On Wed, Apr 1, 2015 at 1:17 PM, Sam Smith <samsmith(a)wikimedia.org> >> > wrote: >> >> >> >> There's a great set of recorded hangouts between Kent Beck, Martin >> >> Fowler, >> >> and DHH titled "Is TDD dead?": >> >> http://martinfowler.com/articles/is-tdd-dead/ >> >> >> >> As with that talk, I'd highly encourage you to take the time to watch >> >> them. >> >> >> >> –Sam >> >> >> >> On Wed, Apr 1, 2015 at 6:07 PM, Corey Floyd <cfloyd(a)wikimedia.org> >> >> wrote: >> >>> >> >>> This is from a while back, but I finally got around to watching it. I >> >>> think it is a really good questioning of our assumptions around >> >>> testing (and >> >>> of course it is a controversial talk - it is DHH) >> >>> >> >>> To me, the TL;DR was: >> >>> >> >>> - The main goal of writing code should be creating maintainable code >> >>> with >> >>> clear intent. >> >>> - While unit testing is good, it is not a panacea for planning good >> >>> architecture or system testing. >> >>> - Good unit testing coverage will not spontaneously birth good >> >>> architecture and at times it can even work against code clarity. >> >>> - System testing is a better representation of how our code works >> >>> - Unit testing should support our goals, and not become a goal in and >> >>> of >> >>> it self. >> >>> >> >>> I highly encourage everyone to carve out some time to watch. >> >>> >> >>> http://www.youtube.com/watch?v=9LfmrkyP81M >> >>> >> >>> -- >> >>> Corey Floyd >> >>> Software Engineer >> >>> Mobile Apps / iOS >> >>> Wikimedia Foundation >> >>> >> >>> _______________________________________________ >> >>> Mobile-l mailing list >> >>> Mobile-l(a)lists.wikimedia.org >> >>> https://lists.wikimedia.org/mailman/listinfo/mobile-l >> >>> >> >> >> >> >> >> _______________________________________________ >> >> Mobile-l mailing list >> >> Mobile-l(a)lists.wikimedia.org >> >> https://lists.wikimedia.org/mailman/listinfo/mobile-l >> >> >> > >> > >> > >> > -- >> > EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle >> > IRC: bgerstle >> > >> > _______________________________________________ >> > Mobile-l mailing list >> > Mobile-l(a)lists.wikimedia.org >> > https://lists.wikimedia.org/mailman/listinfo/mobile-l >> > >> >> >> >> -- >> Dan Duvall >> Automation Engineer >> Wikimedia Foundation > > > > > -- > EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle > IRC: bgerstle -- Dan Duvall Automation Engineer Wikimedia Foundation