Category Archives: TDD

Elaborating on “it depends”

On the discussion on “When should I test?”, I followed up with a conversation: When it provides value. When is that? It depends. And it truly does depend. But upon what? That’s trickier to answer – and there is no … Continue reading 

| 5 Comments

Integrating and isolating the container in tests

In unit tests, an IoC container rarely enters the mix. In integration tests, or more end-to-end tests, I like to use the exact same configuration for the container as I do in production. Recreating production scenarios and environments in tests … Continue reading 

| 6 Comments

Why do TDD?

Because sometimes your test passes the first time you write it. Either you’re done writing any more code, or your understanding of how your code is supposed to work is wrong. Both paths lead to a better spot than without … Continue reading 

| 9 Comments

Are you Mocking Me?

Jimmy has had a couple posts (mocks, mocks, and less mocks) that prompted Derick to post this on his experience with tests – I’d like to add my thoughts to mix.  First, let me say I’m not offering an answer … Continue reading 

Also posted in Uncategorized | 4 Comments

Defining unit tests

I don’t know where I got off the tracks on this one, but I’m really liking Michael Feathers’ definition of a unit test: A test is not a unit test if: It talks to the database It communicates across the … Continue reading 

| 16 Comments

Putting mocks in their place

Awhile back, I talked about 3 simple rules for Rhino Mocks: Use the static MockRepository.GenerateMock method.  Don’t use an instance of a MockRepository, and don’t use the GenerateStub method. If the mocked instance method returns a value, use the Stub … Continue reading 

| 15 Comments

Capturing Rhino Mocks arguments in C# 4.0

As a quick review, a test fixture has inputs and outputs.  We set up our test fixture by configuring inputs.  We observe the results through the fixture’s outputs. Inputs and outputs can be grouped into direct and indirect variants.  Direct … Continue reading 

| 1 Comment

Willed and forced design

Roy Osherove, as a TypeMock employee, presents quite a dilemma from opinionated TDD blog posts simply because whether he has one or not, there’s always the question of agenda.  Which is quite unfortunate, everyone has some sort of selfish agenda … Continue reading 

| 9 Comments

How not to implement a failing test

One of the first things I change in ReSharper, along with one of my biggest pet peeves is a failing test that fails because of something like this: public class CombinedStreetAddressResolver : NullSafeValueResolver<Address, string> { protected override string ResolveCore(Address model) … Continue reading 

| 17 Comments

Simple BDD/TDD

Todays theory is most tests and specs should be very short (2-3 lines), have at most a setup for context establishment, avoid the majority of test framework features as they should be used as an exception and not as a … Continue reading 

Also posted in Uncategorized | 1 Comment