I've moved my blog to a new engine. If you're subscribed to my blog using Feedburner, which you should be :), then nothing has changed. If you're subscribed directly, then please update your feed to use Feedburner

I'll gradually port all the old entries to this new engine, but for now you can find them at:

Tech Blog

Delphi Blog (deprecated sometime ago and merged with the previous, now this one)

If you were subscribed via www.delphifeeds.com and you're still interested in my non-Delphi related stuff I suggest you subscribe to Feedburner because Delphifeeds filters posts and only allows things with certain keywords through (i.e. Delphi, CodeGear, etc.) 

I try, as much as I can to practice TDD, because I truly believe that it helps me shape the design, and that is the primary objective of TDD, not tests. Testing is a nice side-effect. As such, tests serve as specifications; reading a test should give you a clear understanding of what the SUT does. However, reality is not always the case, so the more help you provide to your audience (including yourself), the better. Part of that resides in how you name your tests.

Action_Result_Condition

Let me first point out that I'm not too fond of method names having underscores, but I do find it no doubt easier to read. Which do you find easier?

GetCustomerShouldReturnActiveCustomer

or

GetCustomer_Should_Return_Active_Customer

Before continuing, let me also say that in the context of non-test methods, if you need to use underscores for naming methods, you're probably doing way too much in the method to begin with and it could probably be re-factored. However, tests are a special case.

A test validates certain functionality under specific conditions (or lack of them). By indicating this in the test name, it makes it not only easier to understand the specification, but to also validate the actual test. Take the following example:

   1: [TestMethod]

   2: public void ValidateGetActiveCustomer() {

   3:  

   4: }

without reading the code, you really don't know what that test is meant to do. All you know is that it validates a GetActiveCustomer. But under what conditions? Since the only reference you have is the code, if it's wrong, that is, the test is written incorrectly, you're pretty much lost. You're running that test and thinking all is ok when really it isn't.

Now let's take a look at the same test but with a different name

   1: [TestMethod]

   2: public void GetActiveCustomer_Returns_Customer_When_Given_Valid_Id() {

   3:  

   4: }

This clearly indicates the intentions of the test. At first sight, without even looking at the code, you know what the test is trying to accomplish, and thus providing you a basis by which to validate the actual test code.

You could say that the name is too long. So? You short on bytes? Or on display settings? You could also argue that the Returns_Active_Customer is redundant. Sure, it might be in this case, but that's because GetActiveCustomer more or less indicates what that particular action should do. But there are cases when this does not apply. Let's look at another example

   1: [TestMethod]        

   2: public void ValidateDeleteCustomer() {

   3:         

   4: }

ValidateDeleteCustomer, what does it do? When does it fail? When does it pass?

On the other hand, the following test is telling me not only under what conditions DeleteCustomer should work, but is also clearly indicating a requirement of the program: when a customer has no orders, you can delete it.

   1: [TestMethod]

   2: public void DeleteCustomer_Deletes_Customer_When_Customer_Has_No_Orders()

   3: {

   4:     

   5: }

Here's another example:

   1: [TestMethod]

   2: [ExpectedException(typeof(Exception))]

   3: public void DeleteCustomer_When_Customer_Has_Orders_Throws_Exception() {

   4:  

   5: }

   6:  

Again, as with GetActiveCustomer, we know that this test throws an exception by looking at the test attribute. However, this is something we don't see in a test view/run.

Irrelevant of whether you use underscores or not, use long names or short names, what is also very important is to establish a convention and stick to it. At the very least, all tests in a project should follow the same convention, and if you can get a consensus with your team across different projects, even better.

You like planes? You'll love this virtual tour...

Better not to use datamodules than to use them incorrectly...

Want to find out more, come to SDC this October

This isn't the first time it's happened...serious memory leak.  Sitting on a blank page, just going up and up and up.

Using a IoC container (irrelevant which one but let's assume it's Unity). Here's my main method:

And there's my CustomerController class. Assuming this code compiles, you see anything "wrong"?

Theater Security really annoys me. A couple of days ago I made a reservation for one night in a Hotel. I called the Hotel directly and they asked for my details, the typical: full name, number of nights, etc. I offered to give them my CC number over the phone and they said that they don't allow for that; the correct procedure is to write the numbers down (in handwriting) on a sheet of paper, put my full name on it and fax it to them (note there is no requirement to sign it). So I do that, and call them back to make sure all is in order, and it seemed to be.

Today, I get a call from them, informing me that I did not correctly follow their instructions. It seems I had to also fax them a copy of my card.

"Why?", I asked. "Company policy". "Why?", I asked again. "Sir, it's Company Policy". After going back and forth a couple of times, she tells me that they need to have some "physical" proof of the validity of the card. I told them to just charge me the room now to make sure the number is valid and save me the "trouble" of faxing it to them again, to which she replied "well once you send the copy of the card, please indicate on the piece of paper that you authorize us to charge the room now", at which point I decided to give up and send them the fax.

However, for some odd reason, my fax machine switched to Low quality when the fax was going through. Unsurprisingly when I called them back, they told me that the card had come through completely black; they couldn't see anything on it. I asked her if I needed to now find another fax machine to send it to her in higher quality, to which she replied no. She said that this was normal, that all customers cards pretty much were unreadable once they came through the fax machine, and that was the reason why they ask for the numbers to be written down in handwriting. Since I had already done this, it seemed all was OK and my reservation was now confirmed.

I then asked what was the whole purpose of sending the card if it was illegible, to which she politely replied: "It's Company Policy Sir".

Kind of reminds me of the same type of theatrical security we have to suffer at airports. I once asked asked one of the security guards at Malaga Airport why I had to switch on my laptop for him to see it boot up Windows. I was expecting something in the line of "Sir, it's policy". Instead he told me to ask those that suffered the attacks in New York. No comments!