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
38 Public Repositories
angular-tic-tac-toe
AspNet-DataAccess-Example
AspNet.WebApi.Example
AspNetCore.SimpleExample
AspNetCore20ViewComponents
AzureFunctions.Sample
basic-mvvm-samples
bootstrap-grid-example
CopperStarSystems.WindsorHelpers
DataTemplating-With-Triggers
DelegatesExample
DependencyInjection.GettingStarted
DispatcherTimerTestingExample
DoctorsNotes
dotnetcore-sample
ElmahExample
EventsExample
exploring-wcf
GenericCalculationExample
InteractiveBrokersConsoleClient
jquery-ajax-example
mono
MVC-StudentPairingExample
mvc6-view-components
mvvm-drag-drop
NetCore.Globalization.Example
postsharp-example
SelfBootstrappingAssembly
serilog-sinks-datadog-logs
tdd-hello-nunit
3 Public Gists
You are here: Home » Archives for Code Quality

Refactoring for Testability: Factories for Creation

January 18, 2017 by Ed Leave a Comment

Picture of a factory
Factories are for building things.

In the real world, Factories manufacture items for output.  In software engineering, Factories create object instances for us so we can avoid using the “new” operator.  Factories also give us substantially more control when testing, and can even provide a means of verifying “Black box” operations.

Why would we want to avoid the “new” operator?  Isn’t that what it’s there for?

Well, yes, but newing up a dependency within a class goes against the concept of dependency injection.  Thinking back to our ReallyHardToTest class, we know we’re creating a new instance of SomeModel in the constructor, and one of our methods provides a way to change the SomeModel instance.  The problem is that since we create the instance within ReallyHardToTest, we cannot control it or even verify that an instance is created.  Furthermore, we can’t verify that the SetFilename method actually does what it says on the tin because the SomeModel instance isn’t exposed publicly by that class.

Factories Help Us Build Things

At its root, the factory pattern (there are actually a few variants) encapsulates the logic for creating instances of particular types.  When employing these patterns, now dependent classes can have a factory injected, and then ask the factory for a new instance when they need it.  Since the factory is injected, we can control it at test time – we even get to control the instance returned by the factory!

In advanced scenarios, for example when a factory will be invoked repeatedly, we can use advanced features of Moq, including SetupSequence() to return different instances in a specific order.

Continue Reading

Refactoring for Testability: Remove Static Dependencies

January 16, 2017 by Ed Leave a Comment

Challenge:  Classes with Static Dependencies are Difficult to Test

Static Dependencies pose a set of challenges to testability, most notably:

  • Static Dependencies cannot be mocked
  • Due to their nature, static dependencies are rarely injected so they are hidden dependencies

In my prior post, I showed a very difficult-to-test class that uses the static System.IO.Path.GetFileName method.  Today, we’ll do some refactoring on that class to make it more testable!

Continue Reading

Battling Complexity: Tell It to the Monkey

January 15, 2017 by Ed Leave a Comment

My students often ask me “How can I tell if my code is too complex?”  There are a lot of different answers to that question, but I thought I would share my favorite complexity detection tool with you – a tiny purple stuffed monkey:

Manage complexity by explaining your code to an inanimate object
Look deep into my eyes and explain the code…

I adopted the idea from a great concept called “Rubber Duck Debugging” that I read about in the phenomenal book “The Pragmatic Programmer”.  I’m not really a duck guy so I went with a monkey instead.

The basic concept behind it all is to explain your code to your duck/monkey/other inanimate object, step by step.  If it takes you longer than 1-2 minutes to explain a method, it’s probably too complex and should be refactored to something simpler.

Well that sounds great and all, but how exactly do I reduce a method’s complexity?

Good catch – “Just simplify it” is unacceptably hand-wavey and doesn’t really provide much guidance.  One good approach for reducing complexity is called the Single Level of Abstraction Principle (SLAP).  As might be apparent from the name, SLAP recommends that all statements within a given method exist at the same “Level of Abstraction”.

OK, but what’s a Level of Abstraction?

Continue Reading

© 2019 · The TDD Guy