- 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/b428a620b4b30631b7925b...
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