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
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
+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
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
- 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
- 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
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/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
-- Dan Duvall Automation Engineer Wikimedia Foundation
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l