Having read the quick start at nspec.org, I realized that NSpec might be a useful tool in a scenario which was becoming a bit cumbersome with NUnit alone.
I’m adding an OAuth (or, DotNetOpenAuth) to a website and quickly made a mess of writing test methods such as
[Test]
public void UserIsLoggedInLocallyPriorToInvokingExternalLoginAndExternalLoginSucceedsAndExternalProviderIdIsNotAlreadyAssociatedWithUserAccount()
{
...
}
… and I wound up with maybe a dozen permutations of this theme, for the user already being logged in locally and not locally, the external login succeeding or failing, etc. Not only were the method names unwieldy, but every test needed a setup that contained parts in common with a different set of other tests.
I realized that NSpec’s incremental setup capabilities would work great for this, and for a while I was trucking a long wonderfully, with code like
act = () => { actionResult = controller.ExternalLoginCallback(returnUrl); };
context["The user is already logged in"] = () =>
{
before = () => identity.Setup(x => x.IsAuthenticated).Returns(true);
context["The external login succeeds"] = () =>
{
before = () => oauth.Setup(x => x.VerifyAuthentication(It.IsAny<string>())).Returns(new AuthenticationResult(true, providerName, "provideruserid", "username", new Dictionary<string, string>()));
context["External login already exists for current user"] = () =>
{
before = () => authService.Setup(x => x.ExternalLoginExistsForUser(It.IsAny<string>(), It.IsAny<string>(), It.IsAny<string>())).Returns(true);
it["Should add 'login sucessful' alert"] = () =>
{
var alerts = (IList<Alert>)controller.TempData[TempDataKeys.AlertCollection];
alerts[0].Message.should_be_same("Login successful");
alerts[0].AlertType.should_be(AlertType.Success);
};
it["Should return a redirect result"] = () => actionResult.should_cast_to<RedirectToRouteResult>();
};
context["External login already exists for another user"] = () =>
{
before = () => authService.Setup(x => x.ExternalLoginExistsForAnyOtherUser(It.IsAny<string>(), It.IsAny<string>(), It.IsAny<string>())).Returns(true);
it["Adds an error alert"] = () =>
{
var alerts = (IList<Alert>)controller.TempData[TempDataKeys.AlertCollection];
alerts[0].Message.should_be_same("The external login you requested is already associated with a different user account");
alerts[0].AlertType.should_be(AlertType.Error);
};
it["Should return a redirect result"] = () => actionResult.should_cast_to<RedirectToRouteResult>();
};
This approach seemed to work magnificently until I prepared to write test code for my ApplicationServices layer, to which I delegate viewmodel manipulation from my MVC controllers, and which coordinates the operations of the lower data repository layer:
public void CreateUserAccountFromExternalLogin(RegisterExternalLoginModel model)
{
throw new NotImplementedException();
}
public void AssociateExternalLoginWithUser(string userName, string provider, string providerUserId)
{
throw new NotImplementedException();
}
public string GetLocalUserName(string provider, string providerUserId)
{
throw new NotImplementedException();
}
I have no idea what in the world to name the test class, the test methods, or even if I should perhaps include the testing for this layer into the test class from my large code snippet above, so that a single feature or user action could be tested without regard to architectural layering.
I can’t find any tutorials or blog posts which cover more than simple examples, so I would appreciate any recommendations or pointing in the right direction. I would even welcome “your question is invalid”-type answers as long as some explanation is provided.
Beware: I’ve never actually used NSpec, but I use it’s cousin RSpec all the time. It’s my experience with that tool that leads me to the following answer.
I suggest using this naming convention:
class describe_your_class : nspec
{
void instance_method_CreateUserAccountFromExternalLogin()
{
before = () =>
{
account_repository = new AccountRepository();
fixture = new YourClass(account_repository);
}
context["with a valid external login model"] = () =>
{
before = () =>
{
account = CreateValidAccountForTesting();
fixture.CreateUserAccountFromExternalLogin(account);
}
it["creates a user account"] = () => account_repository.count.should_be(1);
}
context["with a null external login model"] = () =>
{
before = () =>
{
fixture.CreateUserAccountFromExternalLogin(null);
}
it["silently does not create a user"] = () => account_repository.count.should_be(0);
}
}
}
In RSpec this would look like:
describe YourClass do
# "#method_name" is a convention that's used in Ruby docs to refer to an
# instance method. ".method_name" would refer to a class method
describe '#create_user_account_from_external_login' do
before do
# the "@" here indicates that these are instance variables
@account_repository = AccountRepository.new
@fixture = YourClass.new(@account_repository)
end
context 'with a valid external login' do
before do
account = create_valid_account_for_testing()
@fixture.create_user_account_from_external_login(account)
end
it 'creates a user account' do
@account_repository.count.should == 1
end
end
context 'with a nil external login' do
before do
@fixture.create_user_account_from_external_login(nil)
end
it 'silently does not create a user account' do
@account_repository.count.should == 0
end
end
end
end
There are other constructs that RSpec provides, so I probably wouldn’t write my spec exactly like the one above, but I would be able to understand someone else’s that I came across. There’s a great RSpec focused site called Better Specs that might give you more inspiration. You’ll have to translate some of the syntax, of course.