BDD follow up

With the recent alt.net uk conference having some good conversations on BDD, thought i'd share this post from Elizabeth Koegh for those that haven't seen it.

very good resource

Technorati tags: altnetuk, alt.net

Behavior Driven Development

At the recent Alt.NET UK conference, one of the topics that received a fair bit of conversation and debate was Behavior Driven Development and Test Driven Development. Specifically whats the difference? And is the difference just semantics?

To me, the differences are just semantics but its those semantics that make it such a valuable approach.

A recent post from Dan North sums it up pretty good:

My goal as a developer is to deliver a system that behaves in a particular way. Whether or not it has tests is an interesting metric, but not the core purpose. “Test-driven” development will cause me to have lots of tests, but it won’t necessarily get me nearer the goal of delivering business value through software. So you can use goal-oriented vocabulary in your development process as well as your code to help maintain perspective on what you are trying to achieve.

The true benefit comes from finding an alternate way of thinking/approaching/communicating the problem.

This is an area I'd like to see the .NET community improve in.
There tends to be too much focus on a new tool or new framework being the solution to a given problem, which ultimately leads to misuse or use without understanding.

It's important to remember that the tool should not be the solution to the problem, it should support solving the problem.

Technorati Tags: altnetuk,alt.net,bdd

Alt.Net UK

I had the opportunity to attend the Alt.Net UK conference the other weekend. All in all, I am definitely glad i took the time.

Ian Cooper, Alan Dean and Ben Hall deserve a lot of credit for putting in the effort of organizing and for both RedGate and Conchango for backing the event. They did an outstanding job providing a hassle free environment for those participating.

The best thing about this conference was its focus on discussing better ways to do things, sharing experiences and NOT a lot on Microsoft bashing.

Sessions ranged from conversations on REST architectures to BDD to how to unit test a database. I could attempt to give summaries of each i attending but rather than do that i will just point you to here. This was another great initiative of this conference. Using a wiki and asking participants to help populate information in one place so a more broad audience can benefit and reference is a great idea.

While I am in no way an expert on the subject, I attempted to lead a session on Evolutionary Database Design and how to use tools such as dbdeploy.net to simplify following that style. But I was happy to see the session follow the open spaces concept, and shift to what those attending wanted to discuss more specifically. Some very interesting conversations around how a one click deployment type upgrading of a database could work in a non networked/very locked down environment. It resulted in a "not so sure how that'll work" answer but definitely presented a good challenge to debate. The other nugget i took away was the interesting idea of treating a stored procedures as an immutable object.

While the open spaces concept struggled a little bit, I still think it is the right way to host this type of conference. It was clear that it was a new concept to many and that led to a somewhat passive participation with a few strong personalities dominating the conversations. I expect the next one will benefit a lot from the learnings of the first.

If i happen to be lucky enough to attend the next one, i plan to.
And if you have the opportunity to attend a similar event, I highly recommend it.

Technorati Tags: altnetuk,alt.net, .net

Resharper - Inline Method

While most of the time my experience as a developer has been in the .NET stack, I've had the opportunity on a previous project to step into Java for 7 months. This gave me the opportunity of working with IDE's such as Eclipse and IntelliJ that have strong support for refactoring.

I've since returned back to the .NET side and have been found wanting.

Resharper is a crucial piece to the productivity of any .NET developer working in Visual Studio, but there's just some things missing. I won't even go into the really big ones.

One simple, small one in particular has been driving me absolutely bonkers lately:
No support for Inline Method

What makes me truly sad is that i see no indication that the next version (Resharper 4.0) looks to include this.

Can anyone answer why?
Is it significantly harder to implement in Resharper than in IntelliJ?

But I can't really blame JetBrains. That'd be likely biting the hand that feeds me. Deep down I actually blame a colleague of mine for being too good at what he does. He never should have shown so many different ways of safely refactoring code using that refactoring knowing that I'd miss it so. He knows who he is. No scotch for you.*

*note the sarcasm before the flame storm.

Using DBDeploy.NET

To get dbdeploy.net up and running on a project is relatively straightforward.

First thing, if you haven't already downloaded dbdeploy.net, get it from here
I try to keep unnecessary files from being committed to the source control repository, so extract the downloaded zip somewhere (like your desktop) and we'll pick and choose what is needed from there to add to our project.

I tend to follow a project structure similiar to this:


So the first step is to copy the dbdeploy.net\bin folder from the desktop into a tools\dbdeploy folder:

Next we'll want to setup the location we keep all our db related scripts.
In the working directory, add a db folder and below that also add a deltas folder. For dbdeploy.net to work, your database requires a schema version table, so from the dbdeploy.net\scripts folder from the desktop, select the appropriate sql based on the database being used and copy it to your db folder: I also usually keep the database creation script at this location:

Finally, its time to modify our nant build file to include tasks for the db related work.
(Note that i'm omitting some things to reduce the noise, so if something is unfamiliar let me know)

Use of the sql task from nantcontrib is required so ensure you have that available in your tools and import it at a global level in your build file as so:

<loadtasks assembly=""tools\nant\contrib\NAnt.Contrib.Tasks.dll"/>

Add a folder to hold the automated builds upgraded script.

<target name="init" description="initial compilation setup">
<mkdir dir="${build.dir}"/>
<mkdir dir="${build.dir}\db"/>
</target>


Then a task for creating the database:

<target name="db.create" depends="init">
<echo message="create database" />
<sql connstring="${connection.string}"
source="db\createDatabase.sql"
output="${build.dir}\db\createDatabase.out.txt"
delimiter="GO" delimstyle="Line" print="true" batch="false" />

<echo message="create db deploy change log table" />
<sql connstring="${connection.string}"
source="db\createSchemaVersionTable.mssql.sql"
output="${build.dir}\db\createSchemaVersionTable.out.txt"
delimiter="GO" delimstyle="Line" print="true" batch="false" />

<call target="db.upgrade" />
</target>

And finally, the task for upgrading the database:

<target name="db.upgrade" depends="init">
<loadtasks assembly="tools\dbdeploy\Net.Sf.Dbdeploy.dll" />
<echo message="upgrading database to latest version" />

<!-- creates the script -->
<dbdeploy dbType="mssql"
dir="db\deltas"
dbConnection="${connection.string}"
outputFile="${build.dir}\db\db-upgrade.sql"
undoOutputFile="${build.dir}\db\db-upgrade-undo.sql" />

<!-- applies the script -->
<sql connstring="${connection.string}"
source="${build.dir}\db\db-upgrade.sql"
output="${build.dir}\db\db-upgrade.out.txt"
delimiter="GO" delimstyle="Line" print="true" batch="false" />
</target>


I also usually add a task to handle undoing the changes.

<target name="db.upgrade.undo">
<sql connstring="${connection.string}"
source="${build.dir}\db\db-upgrade-undo.sql"
output="${build.dir}\db\db-upgrade-undo.out.txt"
delimiter="GO" delimstyle="Line" print="true" batch="false" />
</target>


Thats it. Infrastructure done.

Assuming your existing build all target is something like this:
<target name="all" depends="clean, init, compile, test, dist" >

To make that recreate the database on each build:
<target name="all" depends="clean, init, compile, db.create, test, dist" >

Or if you only want to upgrade on each build:
<target name="all" depends="clean, init, compile, db.upgrade, test, dist" >

We're now set up to follow a more evolutionary database design, with each additional database change needed being added as a file in the db\delta folder. Remember, the only rule is to follow a naming convention around these scripts. Each file needs to begin with a number, one higher than the previous one.



NOTE: for a good post on using the java version of dbdeploy see Pramod Sadalage blog here

DBDeploy.NET

Taken from www.dbdeploy.com:

dbdeploy is a Database Change Management tool. It’s for developers or
DBAs who want to evolve their database design - or refactor their
database - in a simple, controlled, flexible and frequent manner.

While the java version of dbdeploy has received accolades over the past year, I'm curious how many people are aware that there is a .NET port (available here).

How many people are currently using it? How many would like to be?

I know there is limited documentation or examples of using the .NET version available and have been toying with the idea of doing some posts on how to use dbdeploy.net on a project.

Anyone interested?

(note: expressing interests strongly increases the likelihood it will happen)

Interesting tool - SVNBridge

I see that they have released a V1 of an interesting tool called SVNBridge about a month ago.

The project description sums it up:

allows you to use TortoiseSVN and other Subversion clients with Team Foundation Server. It converts the calls made by your Subversion client to the API supported by TFS.

I prefer to use Subversion/TortoiseSVN as my source control/client of choice.

But in those situations where I'm required to work with Microsoft Team Foundation Server, for example working with CodePlex projects, this allows me to continue to use TortoiseSVN as the client.

Which is nice. Not perfect but good.

Am i alone here???

I'm a strong believer that when developing an application, your main source tree should contain everything that is required to build and run the application. Getting up and running should be as simple as getting the latest version of the code from the repository, running a build and that should be it.

Yes, i am aware of the pragmatism of real world always means there are exceptions.. but i still believe this should be the ideal.

In order to achieve this ability, most projects I've been involved in use the concept of a tools or lib folder at the root of your source tree. These folders contain external dependencies needed by your project in order to build/test/deploy the application.

For example:

projectname
|---trunk
|------- db
|------- docs
|------- src
|------- tools
|----------- nant
|----------- nunit
|----------- nmock2


This works great...except when you have to use Microsoft related technology tool.

95% of Microsoft tools I've attempted to use still have a dependency on an MSI needing to magically install something somewhere to make it work. Which, pardon my french, is crap.

For example... I had a small requirement that the ASP.NET AJAX framework appeared to solve quit nicely. Seemed as simple as adding one line to an aspx page would have done the trick. Plus its an AJAX framework, should be simple to add to the tools folder, add a reference, build and deploy it out.

Nope.

First you have to run an installer, then you have to download and extract another zip file... then you have to repeat on any machine hosting the web application. And have the rest of your team do the same the next time they get the latest version of the code. Crap.

Am i alone in my frustrations of how Microsoft suffers from severe "Installitis" with their developer tools??