Posted by Marcus Wyatt on 29 May 2006
I’ve found the following odd behavioural difference in Assert.AreEqual between NUnit and Microsoft.VisualStudio.TestTools.UnitTesting.
In NUnit you can specify the following test that will pass:
public void IntegerLongComparison()
But when you try to do the same with Microsoft’s Unit testing framework it fails.
So this got me thinking. When comparing value types, do you fail the assertion when the types differ?
One part of me says, No! When you think about it, an integer value of 3 is the same as a double value of 3.
3 are 3, isn’t it…?
Well, yes and no. I’m kind of torn between the two arguments. Not sure which way to go on this problem…
What do you feel is the right behavior?
Currently listening to: ersion) – Winamp *** 1. 2 Brothers on the 4th Floor – Heaven is Here (Radio Version)
Posted in Software, TDD | 4 Comments »
Posted by Marcus Wyatt on 5 May 2006
While I was searching for more information on Behaviour Driven Development, I ended up at Dave Astels blog. Now, many of you in the same headspace as me would probably point out that Dave is one of the pioneering thinkers in this area. Rightly so, but what I found was an interesting post regarding Agile. The first line of the post reads as follows:
I’m in Allen Holub’s talk this morning… “Everything you know is wrong: Inheritance and getters/setters are evil”.
When I read this statement, I found myself almost instantly offended. How can you make a statement like this? Do you want to tell me most of the other leading technical thinkers are WRONG? I mean, come on… We have been practicing Object-Orientation since the middle eighties and all our languages today is build to enable us to develop Object-Oriented software. I continued to read the post and then I found this paragraph:
Allen started off with the classic “tell, don’t ask” talk. He makes a very good point that hadn’t occurred to me before. To really get benefit out of an Agile process (specifically XP) you NEED to be doing OO properly. If you aren’t, you will fail.
I have made this exact point a while back when we where discussing Test-Driven Development. As any TDD zealot knows, you cannot effectively do test-driven development without having loosely coupled objects. Why? The reason is that when you are test-driving a piece of behaviour, you want to be able to test the behaviour in isolation. And to be able to do that, you need to Mock out external dependencies, and to mock the dependencies, you need to expose the dependencies as an interfaces. This brings me back, to another point. State based vs. Interaction based testing. When I started to get into TDD a few years back, I found doing Test-Driven Development was really-really hard. Why? Because I was only doing, state based testing. Since I learned to think in terms of the behaviour that I am trying to implement, I found writing the specifications (tests) are easier and my objects became more cohesive. On to the next interesting bit:
Next Allen moved to why encapsulation is so important and why getters & setters are such a problem. Don’t bother getting flustered about that idea.. he’s 100% on the money. If you disagree you need to learn what OO is. One nice soundbite: “Doing it this way (interface based, using design patterns) lets me have to think less. Thinking is hard… I’d rather just program.”
I agree with Dave on this one. Take for instance the Command-query Separation principle, as soon as you know and understand the principle, you consciously try to adhere to the rules of the principle. By doing this, your code starts to have less public properties and you get methods that are performing only one responsibility. I’m not trying to say that the Command-query Separation principle is the solution to the problem, but that knowledge of Object-Oriented principles will lead you to writing better, more bullet prove code. The Command-query Separation principle is only one in a multitude of Object-Oriented principles.
The bottom line(s):
- There is no such thing as perfect
- Design is a series of trade-offs
- assess risk, then make reasonable decisions
- there’s often is a better way of doing things than the first way you think of
Posted in BDD, OO, TDD, XP | Leave a Comment »