TDD
There are 7 entries for the tag
TDD
I have a tendency to overcomplicate things sometimes. Unit tests, are one such piece of code, that you want to keep as simple and clean as possible, so that other developers can easily find out how your class-or-method-under-test is supposed to work. There’s a principle for that that says it very strongly – “Keep it simple, stupid.” Don’t make it flexible when it does not have to be (just … hard code it). For example, when I was working on IInterceptorSelector support for Castle DynamicProxy, I had to test proxies without target, where return value is set by an...
How do you test collections for equality of their elements? I often used to write my own custom assert for that, something like: public void AssertCollectionElementsAreEqual<T>(IEnumerable<T> expected, IEnumerable<T> actual)
{
var first = expected.GetEnumerator();
var second = actual.GetEnumerator();
int count = 0;
while(first.MoveNext())
{
if(second.MoveNext())
{
...
My last two posts regarding Rhino.Mocks, attracted quite a lot of attention. Focusing on solution I proposed for limiting complexity around creation different kinds of mocks, one thing was pointed out by few people as not the best solution. Ayende called it "in your face! API design", that is stating the kind of mock you want to create explicitly, via method parameter. I don't think that doing it via method name is any less explicit, but let's not go there. Instead, let's think for a while - why do we need 4 kinds of mocks anyway? All differences boil down...
[UPDATE]: Example code is updated. I realized that Kind.Multi is not needed, since you can infer that from passed parameters (when ctorArgs are present, user obviously wants to create MultiMock). I also changed default Kind to Relaxed, since this is the most common one. Ayende wrote today about his ideas for new version of Rhino.Mocks. I like the new syntax (looks similar to what MoQ offers), but there's one more change I'd like to see. Here's the list of all methods of MockRepository, used to create some kind of mock: public T CreateMock<T>(params object[] argumentsForConstructor);public object CreateMock(Type type, params...
Last week I've read quite a few new blogposts about Moq mocking framework. I had looked at it once, when it was first released, but I didn't find it interesting back then. Now that version 2.0 was released I decided to give it a go once again. Here's very simple model I created: It's a class with one method that uses helper object to obtain a value and possibly raise an event. Here's the whole code: public interface IHelper { int Param { set; } ...
Today I had to tear apart and refactor one of core pieces of tool I'm working on. Oh, and I had to do it fast. At first, I was like: "Hey, you can't change that, it was supposed to stay the way it is now!". Next I started to refactor, changing one by one, all the pieces I needed to change in order to achieve desired effect. I was refactoring, compiling, testing... and again refactoring, compiling, testing.... And ultimately when all tests were once again green - I knew I was done. I felt confident. Thanks to TDD and...
I'm currently writing tests for a piece of code that has lot of events flying here and back. Something like: 1: public class Caller 2: { 3: public event EventHandler<CancelEventArgs> MyEvent; 4: 5: public void Call() 6: { 7: if (MyEvent != null) 8: ...