And... we're back!

I had some problems recently with getting my bog working. I was convinced it was a Blogger problem. Turns out I had run out of space on my server, so it was my bad.

Big thanks to Christine at Blogger Support for all her help.

Note: the Atom feed should be working again now too. :)

Linus says no to specs

I just read this in slashdot...

Linus Torvalds raised a few eyebrows (and furrowed even more in confusion) by saying "A 'spec' is close to useless. I have _never_ seen a spec that was both big enough to be useful _and_ accurate. And I have seen _lots_ of total crap work that was based on specs. It's _the_ single worst way to write software, because it by definition means that the software was written to match theory, not reality."

I have got to say, I have to agree with the chap :)

see slashdot for more info...

Selenium as part of the build

We are using Selenium as our automated user acceptance test runner at work. I wanted to include it in our continuous integration script. I couldn't find any information online as to how best do this, so here are my solution:-

We are using CruiseControl.Net with NAnt on our continuous integration server.

Selenium is an automated user acceptance test (UAT) framework written in JavaScript. It interprets tests (in the form of HTML) into commands that it uses to drive and validate a website that it has open in an iframe. To run selenium you open up a browser pointing at your selenium test runner page. Our URL is something like this (but on one line obviously)...

http://localhost/selenium/TestRunner.html?
test=http://localhost/acceptanceTests/TestSuite.aspx&
auto=true&
resultsUrl=http://localhost/acceptanceTests/PostResults.aspx

Parameters

• 'test' - specifies the test suite to run
• 'auto=true' - run as soon as the page loads
• 'resultsUrl' - tells selenium a page it can post the results to
  

The problems I faced were as follows:

• Run the selenium test from NAnt
  
• Detect when the tests have finished running
• Cause the build to fail if any tests failed
  

I chose to write a custom NAnt task to help achieve this. My NAnt task fires up Internet Explorer and tells it to navigate to the aforementioned URL. It then listens to the 'load complete' events in the browser until it gets told the final 'PostResults.aspx' page has been loaded.
The PostResults.aspx is a simple ASP.Net page that saves the passed in test results out to a file in a well known location. The NAnt task then checks this file to see if any tests failed. If they did then it throws a Build Failure exception. If not it just completes successfully.

This worked really well.

Here is an excerpt from our NAnt script:


<target name="--runSelenium">
<trycatch>
<try>
<selenium
seleniumUrl="http://localhost/selenium/TestRunner.html"
testsuiteUrl="http://localhost/acceptanceTests/TestSuite.aspx"
resultsUrl="http://localhost/acceptanceTests/PostResults.aspx"
errorLogFile="C:\temp\Log\error-results.html"/>
</try>
<finally>
<exec program="taskkill" commandline='/FI "windowtitle eq Selenium*"' failonerror="false" />
</finally>
</trycatch>
</target>



I have been thinking of making the 'PostResults.aspx' page take the 'errorlogfile' uri as a parameter. Currently this filename is duplication. I would also like to allow the NAnt file to specify a timeout for the selenium process. I could also move the 'taskkill' logic into the NAnt task.

Here, you have a go:

• Download the project from here .. (Update: Sorry this file was lost a couple of server moves ago. If anyone fancies giving writing it a go, let me know so I can reference it. It wasn't hard to write.)


• Drop the Selenium.Tasks.dll into your NAnt/bin folder.


• Put the above NAnt code in your NAnt script..


• Write yourself a PostResults page (check out the selenium site for details)
• Away you go.
  

When I get time I'll post about how we are generating out selenium tests from C#, which is allowing us to remove duplication and make really succinct tests.

Wrong Problem

I saw some code the other day that totally impressed and disheartened me.

If the code could be likened to a car it would be a car with the best suspension system every invented able to give the driver a smooth comfortable drive. The car would also be sporting a lovely set of square wheels.

Quite some time and effort had been put into solving how to handle the bumpy ride, but they missed the real problem.

It is far too easy to fall into this trap.

So what's next?

Code is a document. A document is written in a language and describe something of meaning. A language is a bunch of terms and a grammar that give the author a framework to present their meaning. In programming, the 'document' is intended to describe a set of instructions that the computer can understand. What form does the computer want these instructions? Well as a document in another language. So a compiler just translates the code from one language to another right?

Translation involves two stages, transforming the original document into an 'understanding' or model of the documents meaning, then expressing this again in another language.

When dealing with a human translator you can say anything. Where there is ambiguity the translator can then ask questions to ensure he has captured the meaning correctly. He can then express the meaning in the new language. The process is interactive.

Your IDE/Editor should be just as interactive.

The future of computing is in making the interaction as simple as possible. The smarter the IDE the simpler the interaction. When the translator knowns what you mean you should be able to stop typing. When the translator is confused it should tell you. Working with and IDE should be a conversation.

Unit testing is good! Unit testing is the gateway to example driven programming. 'When I do X and Y, Z should happen'. This is a form of requirement specification.

Talking of which... It is easy to see that any 'requirements' document that completely explains the requirements of the system is code. The code is just in a language that is much harder to create a software based translator for, so we use humans to achieve it. To me this is the least rewarding form of programming.

With OO software development the codebase breaks down into the model, business rules and user interface. There is also persistence and networking etc. but lets ignore those for now.

The model is just a way of extending the terms in the language you are using to allow you to more concisely explain the system behavior(business rules) you wish to explain to the computer.

If you are extending the terms in the language why not the grammar too. You are then describing your own Domain Specific Languages. JetBrains are doing great job in this area. They intend to create a development environment that allows you to create a programming language quickly that represents the problem domain. They also want to provide you with an intelligent 'editor' for your language capable of intellisence, refactoring etc. This is very exciting. The other approach is to use a language like Ruby or Smalltalk where the language lends itself to easily being extended to include your new concepts.

It would be possible to have the IDE aware of unit tests. Evaluate the unit tests against the current codebase. It could then give you realtime feedback on what code is covered by tests. It could remember the code coverage for each test. Any change you make to the codebase from that point on that effects an existing test forces that test to be re-evaluated. If the test then fails the user is notified. 'Your change just invalidated one of your tests'. Faster you get feedback means less bugs.

IDEs should be more intelligent. I don't just mean smart. I mean AI intelligent. A mixture of automatic refactorings, 'good' design heuristics and Genetic Algorithms could lead to a system that automatically generates the simplest code solution that meets all the requirements (unit tests). Programming would then be the process of coming up with examples where the existing solution fails to meet the requirements.