(w)asp.net - parrots

Parrots on CodeProject

Sat, 03 Sep 2011 20:23:28 GMT

A few days ago I published an article about Parrots on CodeProject. It can be found here.

Background and concepts

Sun, 14 Aug 2011 16:56:27 GMT

The more I work on Parrots and the ideas I have about it, the more I manage to give it a narrow and precise context. This is an important step, because it helps users to decide if and when they should use Parrots instead of any other mocking library around.

IMHO, and given my experiences in the last years, I think that classic mocking works perfectly when you do "true TDD", but maybe you do not do TDD, for many reasons:

- you don't like it

- you like it, but developers around you do not

- you and developers like it, but your managers or company think it is a waste of time (sigh)

- you and everyone at your company like it, but then you don't manage to setup a true test driven development process, which indeed is not so easy to build and mantain

- ...

For whatever reason you don't do it, you end up working in a different way, and probably you keep on doing "unit tests" which supply concrete dependencies to your SUTs. They are not unit tests, they are more "integration tests", but they are done during development, and not after. They are not a good thing, we all know it, but there are times when they are the most and the best we can do. It happened to me to work in such a situation, and the only remedy we found to fix this wrong (and quite useless) context was to transform those integration test in unit tests introducing mocking "a posteriori", but often you have to sacrifice code coverage for the same reasons you did not introduce TDD from the beginning. And you really feel you are doing something wrong...

Now the idea is: you cannot do TDD, and you have to work with concrete dependencies, it would be great if "someone" would be able to transform our true dependencies in mock ones automatically, wouldn't it? That's where Parrots enters.

I already talked about this, but now what I want to concentrate on the mindset shift we have here. With classic mocking, you have to fully describe the behavior of your dependencies, because you may not have them yet, so you need a very good library to do it, and in "real world" scenarios your mocks are quite hard to setup. You must concentrate on what depencencies have to do and replicate it with enough precision to "fool" your SUT and make tests go green. With Parrots the mindset is different: you have the dependencies already, and you just want to remove them at a later time, so what you need is just a way to "record" conversations between SUT and dependencies, and to simulate them at a later time mantaining true fidelity with the real conversations. You must concentrate on recording call sequences with "high fidelity", and then on how two call sequences must be considered equivalent. This might not be an easy task, but it seems to me much more generic, because you don't have to deal with defining each call's behavior, but only with instructing someone (Parrots) about how it can distinguish call sequences, without having to deal with every single sequence. It seems to me much more 'declarative', don't you think?

Ok, Parrots is trying to follow this path, and I'm working on it day by day to implement this vision in a consistent way. I already cover several cases although not all of them yet, but I'm doing my best and I don't think it will get too much time.

I will talk more about details soon. Stay tuned :)

Why Parrots

Thu, 11 Aug 2011 22:37:53 GMT

Parrots is my first open-source project ever, for many reasons I never joined one before and it is the first I decided to start, but I've always been attracted by the idea of having a good idea and share it, eventually getting to form a good distributed team of developers collaborating on it.

Of course I'm still very far from getting anywhere, and I really don't know if I ever will, but I already feel happy about my decision for many reasons which I'm discovering day by day:

- it is challenging: I feel some sort of responsibility, I'm writing code that very good developers out there might see, inspect, dissect, criticize, demolish... I have to try my best in order to build something decent and useful.

- it is instructive: the more I add features or fix bugs in Parrots, the more I learn things, and the more I have to learn things, because Parrots belongs to a quite extensive area: code testing; it requires quite good knowledge about the .NET Framework, and being Parrots itself a small framework, it must be written following best practices and design guidelines. I really love to learn about programming and about .NET and C#, and this project is the best way to get in touch with lots of deep and interesting details.

- it is involving: I'm writing code that nobody asked me for and that nobody will ever pay me for... and it's great! So far I decide the features by myself, I work on it at my preferred pace, I play both the "customer" and the "developer" roles, trying to be very demanding towards myself concerning requirements and code quality... Exciting :)

- it is (or might be) useful: many times I felt that something was missing in "mocking area" (the last time I felt this way: today...), "mocks" and its variants are great tools which help us to isolate our "system under test" from other possibly failing components, but "mocks" are not always easy to do, because mocking libraries may have a steep learning curve, and most of all because doing "mocks" can be a quite long and tedious job. If you have to add features over a quite big existing code base, it is quite common that your components have to interact with existing and complex ones in many different ways, and this implies mocking lots of components, lots of calls towards them, and many permutations of parameters and results on those calls. Even if mocking libraries allow us to setup calls with "don't care" rules, it is still very likely that you have to setup dozens of mocks, and for each one of them dozens of calls. If Parrots would ever get to the point I hope it will, a lot of this plumbing code will disappear or will be automatically generated.

- all this is vitalizing: I have had a couple of difficult years about my job, when it was very hard to keep up the interest in programming... since a few months it's over, and Parrots is one more piece of this new phase of my developer life :)

It would be great to discover day by day that the idea is worth going on, that people likes it and that developers want to join me on it... :)

First release

Tue, 09 Aug 2011 22:41:39 GMT

Today I did the first upload to BitBucket of Parrots, a "record and replay" mocking library I'm working on since a few weeks.

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 concrete dependencies, 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... :)

You can read more about Parrots on the project home page.