- 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