File System Wrappers for Unit Testing in C#

I’ve asked this on twitter, and here’s what I got:

• System.IO.Abstractions (looks pretty deep)
• SystemWrapper (I’m not crazy about the file system being used as a mock API)
• Something older

I’d take a look at the first on the list first, if only for it being on github as a sign of advancement.

Test Driven Validation Logic with Extract & Override

In the NerdDinner project, there’s this amazing test (see the bottom, second one).

There are so many things wrong here:

• What is exactly correct about these properties?
• Many magic values
• Multiple tests in a single test
• if it fails,  its hard to find out why

Here’s how I would approach this kind of validation logic:

use Extract and override, with the test setting the flags for all ‘other’ validation functions except the one I’m testing right now. and I’d at least have two tests for each validation logic. This can also be accomplished with multiple classes and an interface, but I find the tests this way are more readable.

Zen of python revisited with code samples

I really like reading this code. I will look deeper into it this week.

Many of the “zen” ideas here speak to me on the unit test level. 

Test Naming Conventions With Unit of Work

When I name my tests I use the name of the “unit of work” as the first part. If the unit of work is bigger than a method, I usually name the test with the name of the initial public method that starts the unit of work. 

Test names are affected by the type of end result we are expecting. So a test might look like this for a return value result:

IsLoginOK_UserDoesNotExist_ReturnsFalse

or like this for a state change result:

AddUser_ValidUserDetails_UserCanBeLoggedIn

or like this for 3rd party end results (when we use mock objects):

IsLoginOK_LoginFails_CallsLogger

the first part is the unit of work. the second part is the scenario. the third part is the expected end result or behavior of the system.

What does the 'unit' in 'unit test' mean?

I used to think it was a method. Then I thought it coule be several methods. then I thought it might be several classes. then I realized it changes all the time.

It means “unit of work”.

A unit of work is a use case in the system, that is initiated by a public method somewhere, and ends up with an end result. An end result can be one of three things:

• A return value(if the public method is a function) or an exception return value
• A noticeable change to the state of the system under test. Noticeable means that the system behaves differently to an end user than it did before. For example - adding a user changes the system behavior to allow that user to login in. 
• A call to a 3rd party system. A 3rd party system is a dependency that we do not have control over in our test. If it touches the file system, or calls the network, or uses threads, or anything that makes our test slow, or inconsistent, it is a dependency we don’t have control over.

The third case (3rd parties) is where we end up using mock objects. In all other cases, we might have stubs to break dependencies, but our asserts will be against the system’s different states, or different return values.

[Video] Vimming - Natural Selection in Visual Mode

My third vimdeo

[Video] Vimming - All about change

here’s my second attempt

[Video] Vimming - Hello World with vim

My first foray into trying to teach vim related stuff. hope you like it.