Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Better code with TDD using the xUnit framework

Ken Bonny
December 06, 2016

Better code with TDD using the xUnit framework

Ever wonder how to get started with Test Driven Development (TDD), why tests matter or how they can save you time? Is it hard to test an aging code base? Not sure how xUnit is a step up from other frameworks?
In this talk about writing better code with unit tests, benefits of tests and easily testable code will become clear. I discuss patterns that work well with unit tests. Different types of tests will be explained. I compare xUnit to other popular test frameworks and highlight its advantages.
All those points will be illustrated by applying them on a fun, little project we build throughout the talk.
All information in this talk can be found in a series of blog posts at https://kenbonny.net/tag/better-code-with-tests/

Ken Bonny

December 06, 2016
Tweet

Other Decks in Programming

Transcript

  1. Shameless self promotion! • Visit my blog at kenbonny.net •

    Read my code on github.com/KenBonny • Hear me rant @bonny_ken • Apparently devs need linkedin.com/in/kenbonny • And if I’m unclear: [email protected]
  2. Overview • Why do we test? • Different types •

    Most popular frameworks • “Live” coding Interrupt me for questions
  3. Why do we test? • It gives certainty that your

    code works • Gets me thinking about my code • Rerunning tests is effortless • Form of documentation • Quickly run code to experiment Produce better code faster
  4. Different types • End to end or acceptance tests •

    Integration tests • Functional or component tests • Unit tests • Regression tests
  5. Available attributes • [Fact] for a test • [Theory] for

    a data driven test – [InlineData] for simple data – [MemberData] for complex data – [ClassData] for complex data • [Trait] for metadata
  6. Retrospective • Distinguish [Fact] from [Theory] • Arrange, act and

    be Assert-ive • Red, green and refactor phases • Initialize in constructor • Inject as much as possible => Loosely couple components • With old code, try to minimize the changes while adding tests until you cover your current functionality • Changes will be inevitable