I like your TLDR/lessons but I would highly recommend remaining critical while watching the dhh talk. He is very dogmatic (like the TDD preachers), and none of them have the truth. It is always about trade offs and suitability of workflow for different teams and individuals.

My takeaways were "people are starting to wake up from extreme religious tdd practices and instead of finding a productive middle ground now they are going to run to the other end of the spectrum, I'm afraid"

On Fri, Apr 3, 2015 at 12:51 AM, Dan Duvall <dduvall@wikimedia.org> wrote:
>>  - 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 :).
>
>
> I would go further and stipulate that clean coding principles apply just as
> much (if not more) to tests as they do to "production" code. Namely: don't
> repeat yourself and make the intent as clear as possible.  Matching
> frameworks help, but writing good tests takes practice.

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/b428a620b4b30631b7925bb6fbe3e63a3b152df8/spec%2Fmediawiki_vagrant%2Fsettings_spec.rb#L212

On Thu, Apr 2, 2015 at 2:00 PM, Brian Gerstle <bgerstle@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.
>
>>  - 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 :).
>
>
> I would go further and stipulate that clean coding principles apply just as
> much (if not more) to tests as they do to "production" code. Namely: don't
> repeat yourself and make the intent as clear as possible.  Matching
> frameworks help, but writing good tests takes practice.
>
>
> On Thu, Apr 2, 2015 at 4:44 PM, Dan Duvall <dduvall@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@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@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@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@lists.wikimedia.org
>> >>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>> >>>
>> >>
>> >>
>> >> _______________________________________________
>> >> Mobile-l mailing list
>> >> Mobile-l@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@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

_______________________________________________
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l