Apparently Google has some inbuilt smarts to detect if it is being attacked by worms or other viruses. How do I know this? I saw this lovely screen today.

When you enter the code, Google works fine, so they are just trying to outsmart unintelligent bots. I hate to guess what a novice user would make of this screen though. I can hear kids shouting, “Mum, I just broke google …”

If you ever wondered how not to build a search engine, just take a look at yellowpages.com.au or whitepages.com.au.
Why? Let me give you some recent examples.

Scenario 1:

I was trying to find the name for my old optometrist in lane cove using the white pages.

Search, “Optometrist” in the business name, and “Lane Cove” for the suburb.

Expected result: Optometrists in Lane Cove only, or “No matching results found.”

Result: 132 matches with optometrists in every Sydney suburb and none from Lane Cove.

Scenario 2:

I was trying to find the phone number for Fibreglass international in Brookvale using Yellow Pages.

Search, “Fibreglass International” in the business name, and “Brookvale” for the suburb.

Expected result: Only Fibreglass International in Brookvale.

Result: 32 matches with every match for fibreglass and every match for international in the suburb.

Give me the physical phone book any day, it’s simply quicker and easier than using the search engine.

Now that I have installed Whidbey Beta 2. I thought that I should implement the tests I designed in my recent post on using cyclomatic complexity to design tests.

To start, I have created a class library called Samples, with a shell for single static CheckTriangle method. I have added the return null statement so we can compile the class.

The easiest way to setup our test project is to right click on the method name and select create tests.

In the resulting dialog, ensure that I select C# tests in the output project drop-down. For some reason the default is VB, a opposed to the language of the library that you are creating the tests for. I am going to call the project Teknologika.Samples.Tests. Visual Studio will now create a new test project, which includes 2 tests: a UnitTest1.cs class and a ManualTest1.mht manual test.

I am not going to use the manual test, so I will simply delete it. I want to pause here for a second to reflect on what we have already done. In around 30 seconds we have created a new test project and have a test shell ready to run. We have already saved a heap of time that we would normally have to spend creating a new class library and setting up nunit just to get to this point. Cool.

The generated code shell will be the starting point for my tests. To keep things organised I have copied my tests into a text document and added that to the test project. I am also going to rename the UnitTest1.cs file to Samples.Tests.cs so it corresponds 1:1 with my class’ implementation. So after the tidy up, this is what my solution now looks like.

The next thing we need to do is to create a default test script that we will data drive. I have changed the generated test into the following:

Once the test finished, and the solution is finished, we should jump in to the Test Manager, by selecting Manager and Execute Tests on Visual Studio’s new test menu, then select and run out test which should pass.

In the next post, we will complete the CheckTriangle method and change this test into a data driven one.

Edjez, an architect on the Microsoft Patterns and practices team, has written an excellent blog post, “One Bad Unit Test..How many angels can dance on the head of a pin?”. He is blogging about his experience when one afternoon he reverted from using TDD to his old design techniques.

At one point during the day there was a couple of hours when my rigor kind of went down. That is something that pairing will prevent, but I didn’t have anyone to turn to (not in the war room). I reverted inch by inch to the ‘old way’, making some notes on paper, hacking a bunch of classes ‘that you just know what they have to do’ with that high-speed caffeine/sugar/videogame high feeling..that you know will you pay for later.

Like I mentioned in a pervious post, no one ever said that changing habits was easy.

I received an email from Darren Barefoot, a
blogger and PR guy who has helped set up the new QA Podcast.

According to Darren, “the idea is a bi-weekly series of 15-20 minute recorded conversations between a couple of QA specialists. The plan is that each session will discuss a particular business or technical QA topic.”

After playing around with the vpc image of Beta 2 for a couple of days, I finally decided to install the beta onto my home machine.

With disk space limitations, I choose to install a cut down release which only included c# and no team foundation client, only to be greeted by the following error:

A quick search in the product feedback centre soon revealed that the issue had been found and logged, and I needed to have Team Foundation Client installed to stop the error from occurring.

Having external access to the issues is a great feature that I will have to incorporate into our own internal defect tracking system, and I hope someone develops something similar to sit on top of a VSTS database.