Antler Framework: TeamCity build server for our open source project

We are pleased to announce the launch of TeamCity build server for the Antler Framework for public viewing.

It is available here.

Antler Framework is a pluggable framework for .NET to work with popular ORMs(NHibernate, EntityFramework Code First) using the same syntax. GitHub: https://github.com/SmartElk/Antler.

Antler Framework: Releasing 2.0 Version

Antler is a pluggable framework for damn-easy good-style working with different ORMs using the same syntax.

"Pluggable" means that you can easily switch, say, between NHibernate and EntityFramework Code First using one line of code. Also you can easily switch your IoC container: currently we have Castle Windsor and StructureMap adapters.

Configuration example (using EntityFramework ORM + Castle Windsor container):

 var configurator = new AntlerConfigurator();  
 configurator.UseWindsorContainer().UseStorage(EntityFrameworkStorage.Use.WithConnectionString(connectionString).WithMappings(assemblyWithMappings));  

Antler Framework has strong architectural background out of the box: you can easily build your layered design using build-in support for UnitOfWork, Repository etc patterns.

If you are interested you are welcomed on GitHub:
https://github.com/SmartElk/Antler

Powershell: Deploying Windows Service remotely

As a big adherent of Continuous Integration practice I often need to deploy a Windows Service on an another computer remotely "by click".

Mostly, this task is performed from our TeamCity Build Server and consists of the following steps:

• Stopping remote Windows Service
• Backuping it's files
• Copying new files into the remote folder where the service is
• Starting remote Windows Service

It's very easy to accomplish these steps using Powershell:

• Get-WmiObject cmdlet is used for managing Windows Service remotely
• Robocopy tool is used for "smart" copying files into remote shared folder

If you are interested you can find the simplified script example on GitHub: 

https://github.com/ialekseev/DeployRemoteServiceExample

NuGet: Publishing different packages from the same solution

Let's say we need to generate different NuGet packages from our solution: core package and some specific adapter packages(e.g. Windsor container adapter package, EntityFramework + SQL CE adapter package).

This raises some interesting questions:

• How not to get confused with different versions when republishing packages?
• How not to forget to republish some package after you updated one of underlying projects?
• How to remember that you need to update some package(because you made some changes in underlying projects) and you don't need to update other packages(because you didn't make any changes to that projects)?

So, how the hell to keep this process simple and straightforward?

My answer is to republish every NuGet package from solution at once.
I have just one script file to run. When I run this file the following is happened:

• All projects from my solution are built in Release mode;
• Tests are run;
• All NuGet packages are created;
• All NuGet packages are published with the same specified version;

When I need to update any package from my solution I just run this script. I do not need to remember which projects from my solution I updated and which package I need to republish(core or some adapter). All I need is to run one script without any potential problems to upload broken package to NuGet repository.

Now I am planning to include republishing step in our Continuous Integration Server(TeamCity) using almost the same script.

See example of the build script in our Antler project: 
https://github.com/SmartElk/Antler/tree/master/build

Antler Framework: use the same syntax to work with different databases and different ORMs.

I am starting to contribute to Antler project which i believe may be useful for many .Net developers as well.

Antler is a simple framework for super-easy working with different databases(SQL CE, Sqlite, SqlExpress, SqlServer, Oracle etc) and different ORMs(NHibernate, EntityFramework Code First) using the same syntax.

Project is at an early stage, but we have a clear understanding of the requirements.

So, what are the requirements?

• Support for multiple storages at the same time.
• Use common syntax to work with them, so you can easily substitute one storage with another.
• Have strong architectural base including UnitOfWork/DataSession/Repository etc. notions.
• Be fully pluggable. For example, it should be damn easy to choose which storage or IoC container to use.
• Good coverage by Unit/Integration tests. Most of the integration tests should pass for any combination of Database/ORM.

Configuration example

 var configurator = new AntlerConfigurator();  
 configurator.UseWindsorContainer().UseStorage(NHibernatePlusSqlite.Use.WithMappings(Assembly.GetExecutingAssembly()));  

Usage example

Adding teams to database:

 UnitOfWork.Do(uow =>  
 {  
    uow.Repo<Team>().Insert(new Team() {Name = "Super", BusinessGroup = "Great"});  
    uow.Repo<Team>().Insert(new Team() {Name = "Good", BusinessGroup = "Great"});  
    uow.Repo<Team>().Insert(new Team() {Name = "Bad", BusinessGroup = "BadBg"});  
 });  

Querying teams from database:

 var found = UnitOfWork.Do(uow => uow.Repo<Team>().AsQueryable().Where(t => t.BusinessGroup == "Great").OrderBy(t => t.Name).ToArray());  

Project is available on GitHub: https://github.com/SmartElk/Antler.
Everyone is welcome!

Integration testing approaches: Should we use in-memory database?

Integration testing is a form of testing that verifies that components of our application properly work together & with external resources(database, disk-drive etc).

Let's say we have application that uses database in some way. How can we cover components that use database by Integration tests?

The most important principle of testing is Isolation:

Tests should be isolated in the data creating and quering from other tests.

So, each good Integration test that uses database should consists of the following steps:

• Cleaning database 
• Inserting testing data 
• Calling component being tested 
• Checking result / database state 

There are 3 popular ways to write Integration Tests:

1. Use the same development database for Integration tests 
2. Generate empty database before each test 
3. Use some in-memory database 

1. The first choice is to use the same development database for testing. This choice is the worst one, because we can't populate development database by testing data without breaking Isolation principle.

So, it's read-only mode testing. We can test some read-only requests to database, but even then, we are unable to make assertions well, because this data is fragile(we can make changes in our development database at any time and tests will be broken).

2. The second choice is to generate empty database with testing data before each test.
It's good practice to have testing environment that resembles real production environment as close as possible. So, in this case we use the same database-engine for testing as production's one, which makes possible to catch some database-specific problems early.

Disadvantage of this approach is that Integration tests can be pretty slow.

3. The third choice is a to use in-memory database.
If for some reasons we can't use the second choice then we can use in-memory database for testing. It's the compromise choice, because we can ensure Isolation of our tests + high speed of execution, but we sacrifice the closeness to the real environment.

Sqlite is a great example of such database.

For example, if we use NHibernate it's very easy to inject Sqlite database(instead of our real one) in our tests. This database will be based on the same NHibernate mappings and will use the same database-logic.

If you are interested in this approach, you can find example project of using NHibernate + Sqlite for testing on GitHub.

JasmineJs integration with ReSharper & TeamCity

JasmineJs is a great framework for testing JavaScript code.

We'll discuss here how to integrate it with other amazing products: ReSharper 7 & TeamCity.

Download

You can download standalone example here(with additional files to run tests from ReSharper & TeamCity).

This package contains two folders: SpecRunner and YourWebSite. We’ll need them later.

JasmineJs + ReSharper 7 = Friends

To run client-side tests without dependency on your browser we can use PhantomJs WebKit.

Put files from downloaded SpecRunner folder somewhere in your solution.

For example, in my solution these files are located in MyProject/Testing/Client/ folder.

Now we can configure ReSharper to use PhantomJs:

Now we can create JS-files with tests, and run them directly from Visual Studio(thanks to ReSharper) without running our browser(thanks to PhantomJs):

You need to include necessary scripts(scripts to be tested + their dependencies) using reference syntax.
However, note that we don’t need to include JasmineJs scripts, because ReSharper has it’s own inside.

JasmineJs + TeamCity = Friends

Preparing project for running JS-tests from TeamCity 

Put downloaded YourWebSite/lib/ folder in Scripts/Jasmine/ folder of your Web project.

Put downloaded YourWebSite/SpecRunner.htm file in the root of your Web project.

For example:

Then you need to configure SpecRunner.htm to include all necessary scripts:

• JasmineJs scripts(ReSharper doesn’t need them, but TeamCity does); 
• Source files to be tested + their dependencies; 
• Spec files with tests; 
• jasmine.teamcity_reporter.js 

Note, that we include jasmine.teamcity_reporter.js that is needed for integration with TeamCity.

Example of SpecRunner.htm:

Configuring TeamCity for running JS-tests from our project

We need to create additional Build Step in TeamCity:

Note, that we specify Working directory as Testing/Client/ folder of our solution(where we put downloaded files from SpecRunner folder).