Showing posts with label English. Show all posts
Showing posts with label English. Show all posts

Sunday, September 5, 2010

How to integrate MSpec into Hudson CI server

If you’re find this post, you might already know what is MSpec and Hudson CI server. If not, I’ll tell you.

MSpec (short for Machine.Specifications) is an awesome .Net BDD style testing framework for, which allows you write tests without language noise.

Hudson CI is an open source continuous integration server, which is very easy to install and configure with a user friendly interface. It allows you continuously build you projects and verify the quality of these builds. And it has a lot of plugins, which make developing with Hudson more interesting and fun.

So what does it mean integrate and why should I do this?

MSpec has a command line runner, which can fail the build in case some tests are failing, and it can generate nice HTML report which can be placed in build artifacts. So what else do I need, and why i should bother with Hudson integration?

Because dealing with tests is one of the Hudson core features. It can show you information about tests for a particular build and tests history information, such as when they started breaking, how many new tests were added, how test duration changed from build to build, etc. Hudson can also show nice history trend charts.

TestResult

At the screenshot above you can see the test result for a single build.

 

TestResultTrend

At this screenshot (from another project) you can see tests trend.

And the most fun feature (at least to me) is the test tracking in a Hudson Continuous Integration game plugin, which gives points to user on improving the builds. This is my favorite plugin (ok, maybe after Chack Norris plugin).

SoreCard

Would not it be great if MSpec tests will participate in such activities?

How to achieve that?

So how does Hudson know about all available testing tools for various programming languages? Of cause it doesn’t know about all of them. It works internally with JUnit xml reports, but there are many special plugins for most popular testing tool, which in fact transform testing tool output to JUnit format, thus allowing them to be used by Hudson. Unfortunately, there is no such plugin for MSpec currently. And I’m not familiar with Java to write it :)

Good news is that MSpec can generate xml report (although it not as informative as i would like it to be). And we can write XSLT transformation to convert MSpec xml output to JUnit format and use it to provide test results to Hudson directly as JUnit tests.

So here is such XSLT:

So now you can transform MSpec results to JUnit output in you build script and than use it in Hudson. If you are using MSBuil you can use it XsltTransformation task to do the conversion:

And finally you configure Hudson to use test results by specifying converted xml output.

PublishTestResults 

Additionally it is a good idea to publish MSpec HTML report. You may do that with help of HTML Publisher Plugin:

PublishSpecs

That is all you need (except of course that you need to write build script which would run you specifications and will generate xml and html reports). At the end you may see you specifications included as usual tests in Hudson. And as a bonus you get nice HTML report:

HudsonView

The link at the top of the page points to the Specifications HTML report:

SpecificationsReport

Specifications

That’s not all I wanted to say. But I’m a bit tired already. So much words :) Hope it would be useful for someone. And hope that yours Mr. Hudson and Chack Noris will always be happy:).

Sunday, January 24, 2010

Null arguments in a constructor. To check or not to check.

We've had interesting discussion recently, on whether to check constructor arguments on nulls. I want to share my thought on this.

Our coding convention has a rule stating that all public methods arguments should be checked for nulls. So our methods usually looks like this one:
public void SomeMethod(string arg)
{
    Precondition.Argument.NotNull(arg, "arg");
    // Real code comes here...
}
And I'm quite happy with such DbC like coding style. But... with one exception.

I don't like to write code checking for null dependencies in a service constructor. For two main reasons:

  1. It is easier to write tests for the service. In case when particular dependency is not used in test it is easier to pass null instead of creating stub dependencies only to satisfy checks.
  2. It useless in case when all services are instantiated through DI container. That is because, as far as I know, most DI containers will throw an exception by self when it can't find dependency for the service.
I think code will show my point better. Suppose we need a service to login users. Service responsibility will be to retrieve user by the name provided, verify that provided password is correct and to set the user as a current user in the application. In case when supplied user name or password are incorrect, service should log appropriate message.

So service will need some repository to retrieve users, some service to authenticate user and a logger to log messages in case when incorrect user credentials specified.

I'll disregard TDD practice and will show the code before test (shame on me). So the LoginService code:
public class LoginService : ILoginService
{
    readonly IUserRepository userRepository;
    readonly IAuthenticationService authenticationService;
    readonly ILog log;

    public LoginService(
        IUserRepository userRepository,
        IAuthenticationService authenticationService,
        ILog log)
    {
        // This is the subject of discussing.
        Precondition.Argument.NotNull(userRepository, "userRepository");
        Precondition.Argument.NotNull(authenticationService, "authenticationService");
        Precondition.Argument.NotNull(log, "log");

        this.userRepository = userRepository;
        this.authenticationService = authenticationService;
        this.log = log;
    }

    public bool Login(UserCredentials userCredentials)
    {
        Precondtion.Argument.NotNull(userCredentials);
        
        var user = this.userRepository.FindByName(userCredentials.Name);
        if (user == null)
        {
            this.log.Info("Login attempt failed due to invalid user name");
            return false;
        }

        if (!this.authenticationService.PasswordMatches(user, userCredentials.Password))
        {
            this.log.Info("Login attempt failed due to invalid password");
            return false;
        }

        SetCurrentUser(user);
        return true;
    }
}
Lets write a test for scenario when incorrect user name is provided. For this scenario we don't need IAuthenticationService.
[Subject(typeof(LoginService))]
public class when_unknown_user_name_provided
{
    const string UnknownUserName = "Unknown user";
    User user;
    UserCredentials credentials;
    LogSpy logSpy;
    LoginService loginService;
    bool loginResult;

    Establish context = () =>
    {
        credentials = new UserCredentials(UnknownUsername, "stub password");
        var userRepository = MockRepository.GenerateStub<IUserRepository>();
        userRepository.Stub(x => x.FindByName(UnknownUserName).Return(null);

        // We really do not need an authenticationService for this test. 
        // But should stub it only to satisfy null check constraints.
        // Isn't it easier and more readable to use such obviuos construction?
        // var authenticationServiceNotUsed = null;
        var authenticationServiceNotUsed = 
            MockRepository.GenerateStub<IAutenticationService>();

        logSpy = new LogSpy();
        
        loginService = new LoginService(
            userRepository, authenticationServiceNotUsed, LogSpy);        
    };

    Because of = () => loginResult = loginService.Login(userCredentials);

    It should_indicate_that_user_login_failed = () => loginResult.ShouldBeFalse();

    It should_not_set_current_user = () => User.Current.ShouldBeNull();

    It should_log_invalid_login_attempt = () =>
        logSpy.InfoMessage.ShouldBeEqualTo(
            "Login attempt failed due to invalid user name"); 
}
And wait, as far as I have serviceAuthentication instance I might want to ensure that it was not called within a test:
It should_not_use_authentication_service = () => 
        authenticationService.AssertWasNotCalled(
            x => x.PasswordMatches(Arg<User>.Is.Anyting, Arg<string>.Is.Anything));
Seems like a waste of time. Intent is more clear when null authenticationService is used. That's all about testing challenge.

Now lets me return back to my statement that such null checks in a constructor are useless. So what is the advantage they might give? Earlier problem discovering by throwing ArgumentNullException in a constructor, instead of NullReferenceException somewhere while executing method later. I believe that in production code such services should not be instantiated directly by hand, but resolved with DI container (in a recent Ayende's post you can see a very nice picture of dependencies graph). As I've already said, most of DI containers will throw an exception itself if it can't find dependency. But with DI containers even better approach is to test container configuration. For given example test may look like:
[Subject(typeof(ApplicationConfiguration))]
public class when_configuring
{
    Because of = () => ApplicationConfiguration.Initialize();

    It should_initialize_service_locator = () =>
        ServiceLocator.Current.ShouldNotBeNull();

    It should_configure_login_service = () =>
        ServiceLocator.Current.GetInstance<ILoginService>().ShouldNotBeNull();
}
With this approach we get even earlier problem discovering.

Summary: This post explains why using null arguments checks in services constructors is not a good idea. The better approach is letting them be null for testing purposes and testing you DI container configuration to ensure that services may be resolved in a run-time.

Note: Tests are using syntax of the awesome Machine.Specifications framework which you can find here. All the code examples were written without any code editor. So I expect it contains errors.

Tuesday, December 29, 2009

Configuring Log4Net AdoNetAppender with a connection string from application configuration file

I read Ben Scheirman's "Changing log4net connection string at runtime" post and wanted to leave a comment describing solution I use to solve log4net ConnectionString configuring problem. But as I wanted to show some code, it might be better to make a blog post.

So the problem I faced with was:
How to configure log4net AdoNetAppender to use connection string specified in a <connectionStrings> section of an application configuration file?
There is no obvious way to do this in a current release of log4net. But such issue is already fixed in a log4net trunk, thus it will be possible to do so in the next release.

I don't really like to use the code which not yet officially released. So I use a simple workaround - a class inherited from AdoNetAppender with a new property ConnectionStringName. The code is pretty obvious:

using System.Configuration;

using log4net.Appender;
using log4net.Core;

/// <summary>
/// Allows to use a connection string specified in the 
/// <see cref="ConfigurationManager.ConnectionStrings"/> section of an application
/// configuration file.
/// </summary>
/// <remarks>
/// Such feature is already implemented in a log4net trunk (see
/// https://issues.apache.org/jira/browse/LOG4NET-88). But it is not yet released.
/// <para/>
/// TODO: Remove this class as soon as log4net 1.2.11 will be released.
/// </remarks>
public class Log4NetConnectionStringNameAdoNetAppender : AdoNetAppender
{
    private string connectionStringName;

    /// <summary>
    /// Gets or sets the name of the connection string from the application
    /// configuration file.
    /// </summary>
    /// <value>The name of the connection string.</value>
    public string ConnectionStringName
    {
        get
        {
            return this.connectionStringName;
        }
        
        set
        {
            this.connectionStringName = value;

            if (!string.IsNullOrEmpty(this.connectionStringName))
            {
                var settings =
                    ConfigurationManager.ConnectionStrings[this.connectionStringName];
                if (settings == null)
                {
                    string msg = string.Format(
                        "Unable to find [{0}] ConfigurationManager.ConnectionStrings item",
                        this.connectionStringName);

                    throw new LogException(msg);
                }

                this.ConnectionString = settings.ConnectionString;
            }
        }
    }
}

And the log4net configuration looks like this:
<appender name="DBAppender" type="NamespaceWhereClassLives.Log4NetConnectionStringNameAdoNetAppender,AssemblyContainingClass">
    <connectionStringName value="ConnectionStringNameFromConfigFile"/>
    <!-- Other parameters -->
</appender>
This looks like a hack, but it works for me pretty well.

Sunday, September 27, 2009

High/Low generator with SQL

In current project, we use High/Low generator strategy to generate identifiers for entities. (Fabio Maulo wrote a good explanation why using identity is a bad thing). The question I sometimes see in NHibernate forums is what to do if some other applications also use the same database. Usual answer is - implement some service which would generate id, and use it in that applications.
Yesterday I met similar issue. What I needed to do is to insert some fake data using SQL only. For that purpose I wrote such stored procedure:

IF OBJECT_ID('dbo.GenerateHiLoIdRange') IS NOT NULL
  DROP PROCEDURE dbo.GenerateHiLoIdRange
GO
CREATE PROCEDURE dbo.GenerateHiLoIdRange (
    @IdsCount INT
)
AS
/* =============================================================== */
/* == Generates a range of identifiers using High/Low strategy. == */
/* =============================================================== */
BEGIN
    SET NOCOUNT ON;
    
    IF @IdsCount <= 0
    BEGIN
        RAISERROR('@IdsCount should be positive. But was %d', 16, -1, @IdsCount)
        RETURN(-100);
    END

    DECLARE @NextHi INT
    DECLARE @MaxLo  INT
    SET @MaxLo = 100  -- Hardcoded value used over all tables in a database.
 
    BEGIN TRANSACTION UpdateHiLoTable
        
        SET @NextHi = (
            SELECT next_hi 
            FROM hibernate_unique_key WITH (UPDLOCK, ROWLOCK)
        )
        
        UPDATE hibernate_unique_key 
        SET next_hi = @NextHi + 1 + (@IdsCount - 1) / @MaxLo
        WHERE next_hi = @NextHi
        
    COMMIT TRANSACTION UpdateHiLoTable
    
    SELECT @NextHi * @MaxLo + IntValue
    FROM   dbo.Integers(@IdsCount - 1)
END
GO

Main points of procedure:
  • It uses hard coded MaxLo value (100) , which is used over all entities in our application.
  • Calculates new NextHi value based on requested identifiers count and updates hibernate_unique_key table in transaction.
  • To return a result set containing generated identifiers procedure needs some sort of "Integers" table. In my case i simulate such table with a table-valued function.
IF OBJECT_ID('dbo.Integers') IS NOT NULL
  DROP FUNCTION dbo.Integers
GO
CREATE FUNCTION dbo.Integers (
    @MaxValue INT
)
RETURNS @Integers TABLE (IntValue INT NOT NULL)
AS
/* =============================================================== */
/* ==   Returns the [0,  @MaxValue] range of integer values.    == */
/* =============================================================== */
BEGIN
    IF @MaxValue > 9999
    BEGIN
      RETURN;
    END;
    
    DECLARE @Digits TABLE
    (
        Digit INT NOT NULL PRIMARY KEY
    )

    INSERT INTO @Digits (Digit) VALUES (0)
    INSERT INTO @Digits (Digit) VALUES (1)
    INSERT INTO @Digits (Digit) VALUES (2)
    INSERT INTO @Digits (Digit) VALUES (3)
    INSERT INTO @Digits (Digit) VALUES (4)
    INSERT INTO @Digits (Digit) VALUES (5)
    INSERT INTO @Digits (Digit) VALUES (6)
    INSERT INTO @Digits (Digit) VALUES (7)
    INSERT INTO @Digits (Digit) VALUES (8)
    INSERT INTO @Digits (Digit) VALUES (9)
    
    INSERT INTO @Integers
    SELECT Number
    FROM  
        (SELECT 
            Thousands.Digit * 1000 + 
            Hundreds.Digit * 100 + 
            Tens.Digit * 10 + 
            Ones.Digit AS Number
         FROM   
            @Digits Thousands
            CROSS JOIN @Digits Hundreds
            CROSS JOIN @Digits Tens
            CROSS JOIN @Digits Ones
        ) Integers
    WHERE Number <= @MaxValue
    ORDER BY Number
        
    RETURN;
END
GO
Note that number of integers in a function is limited to 10000. But that is what I need.

Now I can generate identifiers in t-sql batches:

CREATE TABLE #TempId (Id INT NOT NULL)

SELECT * FROM hibernate_unique_key

INSERT INTO #TempId
  EXEC dbo.GenerateHiLoIdRange 250

SELECT Id AS Id, 
    'PersonName' +  CAST(ROW_NUMBER() OVER(ORDER BY Id) - 1 AS VARCHAR(255)) AS PersonName
FROM #TempId

DROP TABLE #TempId

In my sandbox database I see such results: