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(a)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/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.
>
- 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(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
_______________________________________________
Mobile-l mailing list
Mobile-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l