The TDD Guy

Adventures in Test-Driven Development!

Find Ed on GitHub!

CopperStarSystems (Ed Mays)
Copper Star Systems, LLC
Phoenix, AZ
https://www.codementor.io/copperstarconsulting
Joined on Jul 10, 2013
40 Public Repositories
AspNet-DataAccess-Example
AspNet.WebApi.Example
AspNetCore20ViewComponents
AzureFunctions.Sample
basic-mvvm-samples
bootstrap-grid-example
bootstrap-modals
CopperStarSystems.WindsorHelpers
DataTemplating-With-Triggers
DelegatesExample
DependencyInjection.GettingStarted
dev-spaces
DispatcherTimerTestingExample
dotnetcore-sample
ElmahExample
EventsExample
exploring-wcf
handlebars-task-list
international-phone-number.poc
jquery-ajax-example
mono
MVC-StudentPairingExample
mvc6-view-components
mvvm-drag-drop
MvvmMasterDetail
NetCore.Globalization.Example
postsharp-example
SelfBootstrappingAssembly
serilog-sinks-datadog-logs
tdd-hello-nunit
9 Public Gists
You are here: Home » Test-Driven Development » TDD vs Non-TDD: A Hypothetical Scenario – Part 3: TDD Environment

TDD vs Non-TDD: A Hypothetical Scenario – Part 3: TDD Environment

April 7, 2015 by Ed Leave a Comment

You calmly lean back in your chair for a moment, taking in the news.  “Wow, this is a pretty big change at this point in the release cycle, but I’m sure Management has considered those risks and the potential for a negative impact.  They’ve committed to this course of action?”  “Yes, and they’re not willing to make any compromises at all – this is a mandate.” says the PM.

For a brief moment, your mind flashes back to the meetings from last year when the team discussed development process, coding standards, and other related practices, unanimously voting to adopt TDD.  You also recall standing your ground in a few conversations with upper management, helping them understand the value of TDD despite their initial impression that it was just busywork.  Your mind then leaps to memories of the initial implementation, how the team had to expend additional effort building test infrastructure, shift their mindset to consider testability, and fully commit to architectural standards.  At first, you recall, the learning curve was brutal but that effort paid rich dividends as the project matured, requiring less and less testing infrastructure while still providing appropriate code coverage.  “And now,” you muse to yourself, “we’ll get to demonstrate to business and management how TDD also mitigates risk from unexpected changes.”

Leaning forward, you say “Ok, well let’s look at what we know and we can work out a schedule.  After taking a quick look, there are 6 changesets associated with the feature we’re abandoning.  We’ve got great test coverage, so we should be able to roll those changesets back one by one, eventually leaving that code in its original state.  The feature itself is not tightly coupled to anything, so we shouldn’t see any unexpected far-reaching effects.  I would say the rollback work could be finished in about a day total.”  “Good”, says the BA, “What else have we got?”  Opening an IM window, you ping your colleagues who are still finalizing their features, to get an idea of their estimated timeframes.  The answers are encouraging, implementation is nearly complete, with about 1.5 days effort remaining.  You relay this news to the BA and PM, adding that this work can occur in parallel with the rollback work.  “And finally”, you say, “there’s QA release certification that usually takes about 4 days.  A few months back we implemented an automated acceptance suite that performs a few hundred end-to-end tests on the system without requiring any human interaction.  It doesn’t replace the certification cycle, but should be helpful for regression testing and also will reduce the amount of manual testing required.  After talking with QA, they believe these automated tests will let them cut between 0.5 and 1 days from the certification schedule.”

After thinking for a moment, you say “So, based on those numbers I would say it’s realistic to say that we could release in as little as 4.5 days if everything goes right, to as much as 6 days if several things go wrong.  So why don’t we call it 6 days, with 5 as a stretch goal.  If we’re lucky we might even be able to beat that, but knowing how important this is, I wouldn’t want to bank on it.”  The BA and PM exchange glances and nod in unison while the PM says “Yes, I think we can get them to buy into that schedule, they were concerned it was going to take weeks – they had a project go south like that in the past and didn’t want a repeat.” “Cool, I’ll let the team know and we’ll get started right away.” you say as you hunker down to communicate the news and start working.

Over the next 5 days, virtually everything plays out as you predicted.  It takes a little bit more than 1 day to rollback the changesets, but the remaining features were all implemented on time.  The certification process only raised a few very minor bugs, and the team even ended up with a bit of free time that they put to use writing a few more automated acceptance tests to save more time next release.  In the end, you release the software exactly as scheduled according to the stretch goal.  On the Friday after release, you are called into the boss’ office, congratulating you on a job well done and offering you a significant project completion bonus.

Share this:

  • Click to share on Twitter (Opens in new window)
  • Click to share on Facebook (Opens in new window)
  • Click to share on Google+ (Opens in new window)

Related

Filed Under: Test-Driven Development, Uncategorized Tagged With: Hypothetical Scenario, TDD

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

© 2021 · The TDD Guy