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 4: The Rest of the Story

TDD vs Non-TDD: A Hypothetical Scenario – Part 4: The Rest of the Story

April 18, 2015 by Ed Leave a Comment

So now we come to the true confessions part of the story…

The fact is, with the exception of the firing part (I plead dramatic license), both scenarios are from my actual career.  In fact, I personally experienced both sides of this story about a year apart, at different stages of the same project, with largely the same development team.  My point is that our team wasn’t magically gifted one day with secret knowledge of TDD, code quality, or related concepts – instead it was a steady process of continuous improvement, actively learning and applying new concepts while refining our practices.  At times it was challenging and painful, but our ensuing successes clearly show the value we gained by adopting and adhering to this process.  My goal with this blog is to share my software engineering experiences and lessons learned with the community at large, focused primarily on TDD, code quality, and engineering best practices, while fostering community discussion on these topics.

Because TDD and code quality don’t exist in isolation from one another, I’ll probably be covering a range of seemingly-unrelated topics.  My hope is that gradually these parts will coalesce into an overall picture providing guidance along with an understanding of where all the pieces fit.  The ultimate goal is to provide a resource outlining ways to:

  • Ensure software robustness
  • Minimize risk of change
  • Improve code testability
  • Improve software architecture
  • Understand and apply TDD principles
  • Use TDD tools to automate integration, acceptance, and regression testing

It may be a long and interesting ride, but that’s what adventures are all about!

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, True Confessions, Uncategorized Tagged With: Hypothetical Scenario, True Confessions

Leave a Reply Cancel reply

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

© 2021 · The TDD Guy