NHibernate, gathering the Java experience saving objects to Relation Databases

Raúl Alarcón García-Cuevas — Mon, 31 Jan 2005 11:22:00 GMT

January is ending, to avoid pass this month without writing to my blog I have decided write about NHibernate, available from http://nhibernate.sourceforge.net/. This open source project, from SourceForge, is a port from Hibernate, a mature java relational persistence tool currently in the 2.0 version.

I don't have tested this tool, but reading the QuickStart guide I feel that it could be a very useful approach to save objects to relational databases. You can start designing the objects or designing the database, NHibernate establish a bridge to connect both. Furthermore, you can change the back-end database server without modifying the objects in your code, anyway you must extend the Dialect name space if the new database manager is not supported.

Currently, the release (0.6.0.0) is been developed, I expect so much from the first version. Keep your eyes on this project, smell like this will be helpful in the future development process.

Testing with Mock Objects and C#

Raúl Alarcón García-Cuevas — Tue, 31 Aug 2004 09:16:00 GMT

Mock objects present an alternative way to make tests for our classes simplifying the testing process and making possible test specific behaviour of our classes when this behaviour relies in other complex classes or subsystems.When we are making unit tests and our class uses other complex classes or subsystems, we could find the following problems:

a) The preparation for the test is hard because of the environment required by the collaborative classes (or subsystems) is complex. In example, think in classes that rely in other classes to retrieve information from the database. To test this kind of classes we need configure a basic data set in the database that represents a snapshot with the concrete context for our testing purposes.

b) We can’t use the subsystem classes because of they had not been developed yet. In early stages of development process, different teams are owners of different parts or subsystems in the global solution. Mock objects let us the opportunity of advance in the development process despites other required subsystem is not available yet.

c) The behaviour that we are trying to test depends on a remotely situation happened in the subsystem. In example, to check if the exception handling when the subsystem rises a technical error, we need to produce the technical error in the real subsystem. This would be impossible if we are dealing with a real subsystem in a production environment.

In all of these situations, we can consider substitute the subsystem with a “mock object” that simulate the expected behaviour required to check our system, we get a really big independency from the subsystem enabling us make our tests more simple, more effective and quickly.

To illustrate the mock object concept, look at this dummy C# example:

We are going to use an existing weather web service to make a little class witch get the weather conditions for the current day. Within the web service methods there is the following:

- GetWeatherConditions(string callerName), returns an integer value representing the weather condition (0 – Sunny, 1 – Cloudy, 2 – Rainy… )

We have developed the “CurrentWeather” class. The constructor will be like:
public void CurrentWeather()
{
...
_webServiceUrl = ConfigurationSettings.AppSettings["Url"];
...
}

The class has the “GetWeather()” method witch connect to the web service, get the weather conditions and save it in suitable private variables. The method always use the string “CurrentWeatherClass” as caller name to make the “GetWeatherConditions” call. We assume that the method has been tested before.

We want in our class a new property to get an image name representing the current weather conditions. To develop this method we are going to start with the test:
[Test]
public void GetWeaderConditionsPictureTest()
{
  CurrentWeather todayWeather = new CurrentWather();
  todayWeather.GetWeather();

  string pictureName = todayWeather.Picture;
  Assert.IsTrue(pictureName.Length > 0);

  //We need check if the Picture really fits
  //the weather condition
  Assert.Fails();
}

In the test, we need check if the picture really fits with the weather conditions retrieved from the web service. In this case, if we use the real subsystem we fall in the following inconveniences:

a) The picture name that the property “Picture” return depends on the real weather, we doesn’t know the weather before the test runs, therefore, we can’t make the correct assertion.
b) If we don’t have a valid connection to the weather web service, the test will fails always.

To avoid it, we can make a Mock Object that represents the web service; in that case we can make another .NET web service with the same signature as the real web service. In the “GetWeatherConditions” method we put logic helping us to make possible the testing:
[WebMethod]
public int GetWeatherConditions(string callerName)
{
  int result;
  switch(callerName)
  {
   case "TestingSunny":
    result = 0;
    break;
   case "TestingCloudy":
    result = 1;
    break;
   case "TestingRainy":
    result = 2;
    break;
   ...
  }
}

After we have the mock-object ready, we must refactor the “CurrentWeather” class to make possible use it from tests, in that case we overload the constructor to provide a way to specify the web service URL to be used, as well as the caller name, the new constructor looks like:
public void CurrentWeather(string callerName, string serviceUrl): base()
{
...
_webServiceUrl = serviceUrl;
_callerName = callerName;
...
}

The unique change required in the original constructor is to put the default caller name:
public void CurrentWeather()
{
...
_webServiceUrl = ConfigurationSettings.AppSettings["Url"];
_callerName = “CurrentWeatherClass”;
...
}

Now we refactor the “GetWeather” method to pass the private variable with the caller name:
public void GetWeather()
{
...
WeatherWebService service = new WeatherWebService();
service.Url = _webServiceUrl;
_currentWeather = service.GetCurrentWeather(_callerName);
...
}

At this point, we can make the required test to check the “Picture” property:
[Test]
public void GetWeaderConditionsPictureTest()
{
  CurrentWeather todayWeather;
string pictureName;

todayWeather = new CurrentWather(“TestingSunny”, @“http://localhost/WeatherMock”);
  todayWeather.GetWeather();
  Assert.AreEquals(“Sunny.jpg”, todayWeather.Picture);

todayWeather = new CurrentWather(“TestingCloudy”, @“http://localhost/WeatherMock”);
  todayWeather.GetWeather();
  Assert.AreEquals(“Cloudy.jpg”, todayWeather.Picture);

todayWeather = new CurrentWather(“TestingRainy”, @“http://localhost/WeatherMock”);
  todayWeather.GetWeather();
  Assert.AreEquals(“Rainy.jpg”, todayWeather.Picture);
}

And that’s all... well, the “GetWeatherConditionsPictureTest” smells like if needs a refactoring ;)

In summary, the mock objects provide us a way to test classes that uses complex subsystems. Introduce mock objects in our solution cause a little extra-coding tasks, refactoring the class to be tested and implementing the mock-object logic, anyway, the extra-coding tasks provide more flexibility in the class to be tested making it better.

There are a lot of alternatives to implement mock objects, for further information checks these URLs:
http://www.pragmaticprogrammer.com/starter_kit/ut/mockobjects.pdf
http://www-106.ibm.com/developerworks/library/j-mocktest.html
http://c2.com/cgi/wiki?MockObject

An introduction to TDD (Test Driven Development)

Raúl Alarcón García-Cuevas — Mon, 10 May 2004 19:24:00 GMT

Here is a very useful article to intruduce you in TDD world, it covers all first questions abount unit testing and how to integrate it in your develop lifetime. The article show fantasticaly how to use NUnit as unit testing tool integrated with C#.

http://msdn.microsoft.com/msdnmag/issues/04/04/ExtremeProgramming/

After you have read the article... think about the following questions:

Are private methods requiered to be unit-tested?
If they are... how you can do it?

TDD & XP

NHibernate, gathering the Java experience saving objects to Relation Databases

Testing with Mock Objects and C#

An introduction to TDD (Test Driven Development)