The Steve Martin reference yesterday was not a song so that broke my streak. Back to song lyrics/titles and a chance to mix Marvelous 3 with my blog. Can't pass that up. Anyway, more "30 Days of Testability" to savor. Please try to contain your excitement ;).
Share a blog post that you found interesting related to testability. Don’t forget to use the hashtag #30DaysofTesting if you share on Twitter.
Technically I've already done this as I shared Alan Richardson's blog post about Testability versus Automatability in my previous post "A Touch of Evil". I could say "hey, already done!" but what's the fun in that? Thus I'm going to go in a different direction today. It's a bit old now but I still think it has some good points to it.
Guide: Writing Testable Code
Granted this post is associated with coding practices and ways to make the code better suited for unit testing but there's still a lot of good things to consider here from a non-coders perspective:
- are we putting flow control in constructors? If so, why?
- are we passing objects that get defined but never used?
- are we consistent with the objects we are passing?
- can we follow the flow easily for what a method is doing?
- does a single method do too much?
this article covers many more situations but the real takeaway is that these coding warning signs are also things that we as testers can consider when we have testability conversations.
Share a blog post that you found interesting related to testability. Don’t forget to use the hashtag #30DaysofTesting if you share on Twitter.
Technically I've already done this as I shared Alan Richardson's blog post about Testability versus Automatability in my previous post "A Touch of Evil". I could say "hey, already done!" but what's the fun in that? Thus I'm going to go in a different direction today. It's a bit old now but I still think it has some good points to it.
Guide: Writing Testable Code
Granted this post is associated with coding practices and ways to make the code better suited for unit testing but there's still a lot of good things to consider here from a non-coders perspective:
- are we putting flow control in constructors? If so, why?
- are we passing objects that get defined but never used?
- are we consistent with the objects we are passing?
- can we follow the flow easily for what a method is doing?
- does a single method do too much?
this article covers many more situations but the real takeaway is that these coding warning signs are also things that we as testers can consider when we have testability conversations.
No comments:
Post a Comment