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:).

Thursday, March 4, 2010

XML file in Visual Studio - Request for permission failed.

Напишу для себе про помилку, яку показувала Visual Studio коли я відкривав xml файл. Бо не знатиму, що робити з цією помилкою, коли вона виникне наступного разу.

Отже ситуація така. Включив до проекту скачаний з інтернету XML файл. Відкрив його в Visual Studio 2008 і побачив таку помилку:





Повідомлення про помилку:
Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.

Якщо в DOCTYPE зазначено url схеми в інтернеті, то відповідно виникає помилка:
Request for the permission of type 'System.Net.WebPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.

При цьому до проекту було вже підключено кілька XML файлів із таким жe DTD.

Гугл мені не допоміг. Здогадався подивитися у властивості файлу. Проблема виявилась простою - Windows заблокувала файл, тому що він був завантажений з інтернету.


Дуже дякую. Це ж мабуть я мав відразу здогадатися? Витратив кучу часу.

Monday, February 15, 2010

Великий піст 2010. Що можна їсти?

UPD: Оновлену схему посту для 2011 року можна подивитись тут.

Сьогодні, 15 лютого, розпочався Великий піст. Для мене це привід змінити себе на краще,
поборотися зі шкідливими звичками. І хоча всі кажуть, що піст – це не дієта, все ж утримання від їжі - це головний атрибут посту.

Яку їжу можна вживати в піст

Є різні правила. Біль та менш строгі. Я користуюсь тими, що описані на сторінці сайту http://www.sestry.ru. Там я знайшов і цю зручну схему:


Отже оcновні правила такі:
  • Не можна їсти м'ясо, рибу, яйця, молоко та інші продукти тавринного походження.
  • У перші два дні посту (15 та 16 лютого) та в передостанній день (2 квітня) - строгий піст. Рекомендується повне утримання від їжі, або невелика кількість пісної їжі.
  • В середу та п'ятницю - «сухояденіє». Не можна вживати ні варену, ні приготовану на пару їжу. Не можна вживати олію. Дозволяються хліб, свіжі, сушені й квашені овочі та фрукти.
  • В інші дні дозволена рослинна олія.
  • В суботу, в неділю а також в свята 25 лютого, 9 березня та 22 березня можна вживати морепродукти. 
  • В Вербну неділю (28 березня) можна їсти рибу. А в Лазареву суботу (напередодні Вербної неділі) можна їсти ікру.
І наостанок, слід пам'ятати, що головне чого не можна їсти - це своїх ближніх.

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.