Azure DevOps, Scrum, & .NET Software Leadership and Consulting Services

Free course! Predicting the Future, Estimating, and Running Your Projects with Flow Metrics

VSLive Vegas 2016: Unit Testing for Mere Mortals Slides & Code


I just wrapped up my first talk at VSLive Las Vegas 2016 — “Unit Testing & Test-Driven Development (TDD) for Mere Mortals”.  Thanks to all the attendees for the great questions — especially the discussion we got in to about unit testing private methods.

As promised, here are my slides and code samples.

Unit Testing & Test-Driven Development (TDD) for Mere Mortals

Unit Testing and Test-Driven Development (TDD) arguably mean the same thing.  They (both describe a way of developing software so that you always know whether or not it’s working.  You write little chunks of code (unit tests) that verify the objects and methods in your application’s code and it helps you make sure that you have PROOF that your code works.  It also makes your code easier to maintain and easier to refactor.  Plus, while it might not feel like it right away, writing using tests makes your development process go a lot faster.

In this session, Ben will discuss what unit testing & TDD are all about, why you should care, and how to do it with C# and ASP.NET MVC.  Along the way, expect to hear about “designing for testability” and some really helpful testability design patterns like the Strategy, Repository, and Adapter patterns.

VSLive Las Vegas 2016 Unit Testing Code Samples

VSLive Las Vegas 2016 Unit Testing Slides

-Ben

SUBSCRIBE TO THE BLOG


3 responses to “VSLive Vegas 2016: Unit Testing for Mere Mortals Slides & Code”

  1. Matt R Avatar
    Matt R

    Thanks for sharing Ben! A question on slide 24 (Advertise Dependencies on Constructor):

    What are your thoughts on good/bad design to give the option to inject a dependency, but not force it?

    So, within the constructor, basically combine the “less awesome” and “more awesome” code example:

    public PersonManager(IPersonalRepository instance)
    {
    if (instance == null)
    m_Repository = new SqlPersonRespository();
    else
    m_Repository = instance;
    }

    So, as the calling code, I know the default behavior is to use a SqlPersonRespository (because somebody documented the API…) and I only inject a dependency if I need to change that default behavior (such as for mocking).

    Pros / Cons?

    Thanks,
    Matt

  2. Matt R Avatar
    Matt R

    Actually, if I took that previous comment example one step further, I’d create a constructor overload that didn’t include a parameter. That way, I’m not forcing the consumer to pass a null parameter in the first place…

    Then, as calling code, I could do either:

    var sqlRepo = new PersonManager(); // uses SqlPersonRepository
    var mockRepo = new PersonManager(myMockRepository);
    var oracleRepo = new PersonManager(myOracleRepository);

    1. Ben Day Avatar

      Hi Matt —

      The option to pass in a null as a parameter feels like you’re inviting bad things to happen. Two thumbs down on that approach.

      I like the “two constructors” version a whole lot better. I actually use this sometimes when I want testability but I don’t feel like taking the dependency on an IoC framework / DI framework. You’ve got a *little* bit of an unadvertised dependency in that class using that approach but if someday you need/want to refactor to remove that dependency, most of the work is already done.

      Honestly, that’s a pretty good design approach.

      -Ben

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.