Unit Testing

Why

What do you think?

Frameworks

  • XUnit
  • NUnit
  • MSTest
  • MSpec (Machine.Specification)
  • TSqlT
  • Jasmine
  • JUnit

DAMP & DRY

A good name is rather to be chosen...

Two things are hard, Cache Invalidation and naming things.

  • DAMP: Descriptive And Meaningful Phrases
  • DRY: Don't Repeat Yourself

Good Practice: Test Names

{UnitOfWork}_{Scenario}_{Expectation}

//
//  Here's an example
//

[Fact]
public void MyFaveUnit_CalledWithGoodParm_ReturnsValidThing()
{
	// Arrange

	// Act

	// Assert

}
				

3 Part Harmony

  1. Arrange
  2. Act
  3. Assert

Arrange

Define your scenario

  • Create Instances
  • Mock Dependencies
  • Initialize Expectations

Act

  • Call your Unit Under Test

AKA 'unit of work'

Assert

  • 'Be Sure That' your expectations were met.

TDD

Test Driven Development

Write tests before you code

Even for objects and methods that do not yet exists

Red, Green, Refactor

  • Red: Write an expectation that fails
  • Green: Write the least code to pass
  • Refactor: All Test MUST Pass, Always

Code Coverage

More is good-er

There is a practical limit