Minimal StoryQ demo

// StoryQ demo

This is a basic demo of using StoryQ.
You need to implement the void methods with wrappers around the system functionality under test.

Note this uses the Given/When/Then pattern as opposed to the normal NUnit Assemble, Action, Assert.

using System;
using NUnit.Framework;

using StoryQ;

namespace Experiments
{

[TestFixture]
public class FirstTest
{

[Test]
public void SunshinePath()
{
new Story(“User Management”).InOrderTo(“Add User”)
.AsA(“Admin”).IWant(“To Add a User to the system”)
.WithScenario(“HappyPath”)
.Given(IHaveEnteredUserName)
.When(IPressSave)
.Then(UserIsAdded)
.And(IAmReturnedToTheMainWindow)
.WithScenario(“UserExists”)
.Given(IHaveEnteredUserName)
.When(IPressSave)
.And(UserAlreadyExists)
.Then(IAmShownErrorMessage)
.ExecuteWithReport();
}

private void IHaveEnteredUserName()
{
throw new NotImplementedException();
}

private void IPressSave()
{
throw new NotImplementedException();
}

private void UserIsAdded()
{
throw new NotImplementedException();
}

private void IAmReturnedToTheMainWindow()
{
throw new NotImplementedException();
}

private void UserAlreadyExists()
{
throw new NotImplementedException();
}

private void IAmShownErrorMessage()

{

throw new NotImplementedException();

}

}

}

NuGet command line

NuGet is microsoft’s attempt at a package manager.
It works well for adding open source code to a visual studio project.
You can even host your own local server.

The basic nuget command-line download goes back to the home server to get the latest NuGet.exe which can then be used to obtain other components – even outside of visual studio.

To get the list of items (with a minimal description) you can use:

nuget list -verbose

Some of the projects are a little vague (or personal demos). Most look very interesting.

Minimal Rhino Mocks sample

var myMock = MockRepository.GenerateMock();
Console.WriteLine(myMock.Execute(“Hello”) ?? “”);

MockRepository mocks = new MockRepository();

var myMock2 = mocks.Stub();
using (mocks.Record())
{
SetupResult.For(myMock2.Execute(“Hello”)).Return(“World”);
}
Console.WriteLine(myMock2.Execute(“Hello”) ?? “”);

I still wonder why mocking frameworks are so popular. Handcrafted mocks seem to do the job quite well and are easy to implement as:

Stub – Ignore inputs and return as little as possible (I frequently return 42 as an integer result)
Spy – Record and log callers.
Saboteur – fail in a controlled fashion (i.e. a stream that will fail with an exception upon the fifth byte read).

If your interfaces are too big then you are not following SOLID properly. If changing the interface causes too many problems then you have not isolated the tests from the code enough (factories and helper methods).