>> - 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