Posted on by Jon

Herding Code 165: Mark Seemann on AutoFixture and Unit Testing

While at the Danish Developer Conference in Copenhagen, Jon sat down with Mark Seemann to talk about AutoFixture and Unit Testing.

Download / Listen:

Herding Code 165: Mark Seemann on AutoFixture and Unit Testing [audio://herdingcode.com/wp-content/uploads/HerdingCode-0165-Mark-Seemann-on-AutoFixture-and-Unit-Testing.mp3]

Show Notes:

  • AutoFixture
    • (00:44) AutoFixture is an open source library that simplifies the "Arrange" part of the standard Arrange / Act / Assert steps in unit tests.
    • (01:20) Jon asks about anonymous variables. Mark says he got that terminology from Gerard Meszaros’ book, xUnit Test Patterns. Anonymous methods and variables are necessary for a test, but their implementation doesn’t matter.
    • (02:23) Mark describes the test data builder pattern, from the book Growing Object-Oriented Software. The pattern works well, but it gets to be repetitive and mechanical to write and maintain, so he wanted to automate it. AutoFixture uses reflection to create the needed instances.
    • (04:00) Jon asks about the usage pattern for AutoFixture.(04:16) Jon asks about the different values returned for strings, ints, etc. Mark explains how that’s changed over time – numbers no longer just return sequential values, they now return random small numbers.
    • (05:20) Mark explains equivalence classes. Jon says "Okay" a lot. You can use AutoFixture in cases where you don’t care about the value; in cases where you do, you can configure what you want to. Mark explains some of the different ways you can use the AutoFixture API to set specific values when needed.
    • (09:15) Jon asks how AutoFixture works with mocking. Mark says there are NuGet packages which will interface with Moq, Rhino Mocks, FakeItEasy and NSubstitute.
    • (10:25) Jon asks Mark what his talk said about equivalence. Mark explains identity and value objects with an example with overriding the equals operator on a money value object. The more you can model your domain as value objects, the easier your tests become. Jon asks if this is an example of TDD driving a good design. Mark says that he tried letting tests completely drive his design a few years ago, but he found that it alone didn’t drive a very good overall design.
  • Testing philosophy, Testing Trivial Methods
    • (15:56) Jon asks Mark about his recent post advocating testing trivial methods. Mark says that his post was in response to Robert C. Martin’s post, The Pragmatics of TDD. Mark makes a case for testing getters and setters – if you decide to use a property rather than a field, that decision probably warrants a test to verify the property is maintaining the behavior that drove the original decision.
    • (20:38) Jon asks how this applies to the example of testing ASP.NET MVC controller code. Mark says he’s in the habit of testing everything, and has written a lot of tools to make writing the tests easy enough that it’s not a concern. The question is, how much does it cost you if a unit of code doesn’t function as designed? Mark explains how a controller action models the data flow in an MVC application, and decomposing the flow allows you to write smaller, simpler, more targeted tests.
    • (25:03) Jon asks how this relates to outside-in testing using tools like Selenium. Mark says that testing at the external boundary is fine if you can, but most applications become complex enough that boundary testing would require an impractical number of test cases.
  • Wrap up
    • (26:04) Mark says that many of these concepts are covered in more detail in Mark’s Pluralsight course.

Show Links:

CategoriesUncategorized