McKelt.com

Remembering Thoughts

Recent comments

Authors

Categories


Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2010

How to use DB Deploy

Download source files:DBDeployExample.zip (4.81 mb)

Here is a quick example of how to use DB Deploy 

This example uses NANT to run DBDeploy which in turn generates the output.sql file.  This is then run against the database causing our changes to be run in and putting an entry in the ChangeLog table to tell you which sql files have been run. 

 To run this sample

  1. Download to a location on your computer e.g. C:\Examples\DBDeployExample
  2. Create a database onyour localhost called DBDeployExample
  3. In a command prompt (Or PowerShell) use NANT to build the solution --(I have this setup as an environment variable setup and simply type 'NANT')
  4. NANT will build the default.build file and run the database changes

 

The NANT output should look like this

   

 




Opening the solution file looks like this





The database should now look like this




The ChangeLog table in the database is used by DBDeploy for change management and will look like this:

 

 


 

The default.build file contains a target that actions DBDeploy

  <target name="script.generate" description="generate a sql upgrade script">
<call target="setup.changelogtable"/>
<call target="setup.builddir"/>
<echo message="Calling dbdeploy with dbConnection=${connstring}..." />
<dbdeploy dbType="mssql"
dbConnection="${connstring}"
dir="${script.dir}"
outputFile="${output.file}"
undoOutputFile="${undo.output.file}" />
<echo message="...finished calling dbdeploy." />
</target>

 

The output file contains all change files found on the file system that are not contained in the ChangeLog table

The following command runs the output script against the database

 

  <target name="script.execute">
<echo message="Executing script ${script.execute.filename} against database ${database.name}..." />
<exec program="${sqlcmd}">
<arg value="${script.execute.extraparams}" />
<arg value="-i" />
<arg value="${script.execute.filename}" />
<arg value="-d" />
<arg value="${database.name}" />
<arg value="-S"/>
<arg value="${server}" />
</exec>
<echo message="...finished executing script." />
</target>

 


Posted by Chris on Thursday, August 28, 2008 11:23 AM
Permalink | Comments (4) | Post RSSRSS comment feed

Active Record and Fake In Memory Repositories in Test Driven Development

Download Project source files:ExampleFakeRepository.zip

Introduction

Here is a simple example of how to use fake repositories in test driven development. 

By using Fake Repositories generated from a binary file we are able to quickly use 'real data' in all our tests.

It is a Visual Studio 2008 solution and uses the Castle project's Active Record as an ORM.

Step 1 – Our Core Model

Our model will consist of 3 classes

 

  • SuperHero e.g. Superman
    • SupeHeroId
    • RealName
    • SuperHeroName
  • Power e.g. Flight
    • PowerId
    • PowerName
  • SuperHeroPower e.g. Superman’s flight
    • SuperHeroPowerId
    • Comments (e.g. Faster than a speeding bullet)

Each of our classes implements an Interface called IIdRetriever

    /// <summary>
   
/// This was created so that the BaseRepositoryFake class can provide a standard

   
/// implementation for fake repositories despite not knowing what property holds

   
/// the Id.

   
/// </summary>

   
public interface IIdRetriever

   
{

       
int GetId();

       
void SetId(int id);

   
}

First we define a base interface that defines all our methods needed for an ‘in-memory’ database

This base interface is called IRepository

public interface IRepository<T> where T : class
   
{
        T Save(T item);
        T SaveOrUpdate(T item);
        T Get(object id);
        long Count();
       
ICollection<T> FindAll(params ICriterion[] criteria);
        void Delete(T item);

    }   

Now for each class we need a repository so we define 3 repository interfaces that implement the IRepository interface with their corresponding class 

  • ISuperHeroRepository
  • IPowerRepository
  • ISuperHeroPowerRepository

public interface ISuperHeroRepository : IRepository<SuperHero>{}

 

Now for the concrete implementations of our repositories the following classes are created 

  • SuperHeroRepository
  • PowerRepository
  • SuperHeroPowerRepository

 

public class PowerRepository : ARRepository<Power>, IPowerRepository{}

   

Step 2 – Create the database, populate data and generate the binary file

 

In the attached project there is a command line utility project that accepts 3 arguments 

  • CreateSchema – will create the tables in the designated database in the app.config
  • PopulateData – will populate the tables with some sample data
  • GenerateBinary – will get our ‘core’ object which contains relations to all our data and binary serialize it into a file

 

 

Step 3 – Creating our fakes for use in tests

 

We will now create fake ‘in-memory’ repositories which use the pre-populated binary data for use in out tests 

Firstly there are some integration tests in the database which ensure the add/edit behaviour is correct when talking to the database.

Secondly there is a folder entitled Fakes 

The main file here is the BaseRepositoryFake which contains all our base methods to mimic a database – yet in memory through an internal collection. By inheriting this class our other fake repositories get the ability to Save,SaveOrUpdate,Delete and find all.
 

Our inheriting fake repositories are as follows

  • SuperHeroPowerRepositoryFake
  • PowerHeroRepositoryFake
  • SuperHeroPowerRepositoryFake 

These simply inherit the BaseRepositoryFake and implement their corresponding interface

public class SuperHeroRepositoryFake : BaseRepositoryFake<SuperHero>, ISuperHeroRepository
 

An explanation of the files in the root of the Tests project

  • ActiveRecordFixture – singleton one time setup for active record
  • RandomHelper – Set Ids and values for our fake objects (As SQL Server identity columns these will be seeded in the DB)
  • SeededRepositoryFakes – contains a fake representation of each repository (e.g. SuperHeroRepository) – data is read from the binary file in these
  • SeededRepositoryFakesCountTest – test to ensure the SeededRepositoryFakes are filled
  • SuperHeroSeed – class that reads from the binary file

 

Download the above sample and run the tests to see this all in action.


Posted by Chris on Thursday, August 07, 2008 10:42 PM
Permalink | Comments (3) | Post RSSRSS comment feed