1. wasp
  2. Parrots

Wiki

Clone wiki

Parrots / Home

Welcome to Parrots

Parrots introduces a (possibly) new concept about "record and replay" mocking for unit testing. It is written in C# and it is intended to be used in C#. It is in a very early stage, but there are already a few things the library can do. You can find out more about it browsing the code and trying the unit tests contained in the solution.

Some background: let's suppose I cannot do TDD, for whatever reason, and for whatever reason I end up writing "unit tests" but using "true" dependencies for my "system under test" (SUT). I know that these are not unit tests, but I still need them during development. So, should I at some point "convert" them "mocking" the concrete dependencies with a good mocking library like Rhino Mocks? Yes, but again, I have no time and, honestly, many times doing mocks is a quite long, tedious, complex and error prone activity, even more if I do no really care about mocks. I just would like to have "stubs", forget about them and have my tests go green...

So, the idea is: I go on writing "integration tests", which talks to the concrete dependencies I already have available, but later at some point I tell my tests, through Parrots, to "record" the conversations happening between SUT and its dependencies. As soon as I do it, the tests convert themselves to use the recordings Parrots did for me, and since then they will stop talking to concrete implementations and switch to the "imitations" Parrots did for me. Now you know why this curious name... :)

Sample:

[Test]
public void AnotherSimpleStringTest()
{
	using (var session = Trainer.Aviary
		.AddParrotFor<IAmSomeDependency>()
		.And.AddParrotFor<IAmSomeOtherDependency>()
		.Finally.RecordOrReplay())
	{
		var sut = new ToBeTested(session.Resolve<IAmSomeDependency>(),
			session.Resolve<IAmSomeOtherDependency>());

		var output = sut.Process("reverse", "wasp");
		Assert.AreEqual("psaw", output);
	}
}

So, the first time you execute such a test, the SUT will talk to the concrete dependencies I configured with my preferred IoC container (so far Parrots talks to Castle Windsor only, but it would be nice to have more of them), recording whatever info they exchange. Then, since the second time and without changing the unit test code, Parrots will enter, and it will redirect the dialogues to "somewhere else", where recorded info can be retrieved and sent to the SUT transparently. The concept is similar to a mock, but the info exchanged are recorded and replayed.

And, there is more. If you change the RecordOrReplay method to GenerateOrReplay, Parrots will not just record the traffic, but it will also generate true Rhino Mocks code following the Arrange/Act/Assert pattern (ok, this is not completely true, "AAA" should mean you can clearly read the Arrange and the Assert part in the body of the unit test along with the Act part, and that's not the case, but the Arrange and Assert parts are nicely isolated and should be easy to find...). You will just have to include the generated code in your unit tests project, modifying it at your will if you think that it can be improved, and you have true mocks with almost no effort. You will just let the Parrots code in place even after including the generated code, Parrots will transparently load the generated mocking code!

More details

You can read more about Parrots here:

1. Dissecting parrots...

2. Call Sequence Equivalence

3. IoC Container Interactions

Summary

So, do you like it? I did some research about the topic which Parrots is about, in .NET and C# areas, but I did not find anything similar yet, so I decided to write Parrots. Let's see if it grows up well in the next weeks, maybe with your help :)

Enjoy it!

Wasp

Updated