// ThomasWeller

Testing Entity Framework applications, pt. 3: NDbUnit

Thomas Weller — Thu, 10 Nov 2011 06:36:54 GMT

Originally posted on: http://geekswithblogs.net/thomasweller/archive/2011/11/10/testing-entity-framework-applications-pt.-3-ndbunit.aspx

This is the third of a three part series that deals with the issue of faking test data in the context of a legacy app that was built with Microsoft's Entity Framework (EF) on top of an MS SQL Server database – a scenario that can be found very often. Please read the first part for a description of the sample application, a discussion of some general aspects of unit testing in a database context, and of some more specific aspects of the here discussed EF/MSSQL combination.

Lately, I wondered how you would ‘mock’ the data layer of a legacy application, when this data layer is made up of an MS Entity Framework (EF) model in combination with a MS SQL Server database. Originally, this question came up in the context of how you could enable higher-level integration tests (automated UI tests, to be exact) for a legacy application that uses this EF/MSSQL combo as its data store mechanism – a not so uncommon scenario.

The question sparked my interest, and I decided to dive into it somewhat deeper. What I've found out is, in short, that it's not very easy and straightforward to do it – but it can be done. The two strategies that are best suited to fit the bill involve using either the (commercial) Typemock Isolator tool or the (free) NDbUnit framework. The use of Typemock was discussed in the previous post, this post now will present the NDbUnit approach...

NDbUnit is an Apache 2.0-licensed open-source project, and like so many other Nxxx tools and frameworks, it is basically a C#/.NET port of the corresponding Java version (DbUnit namely). In short, it helps you in flexibly managing the state of a database in that it lets you easily perform basic operations (like e.g. Insert, Delete, Refresh, DeleteAll) against your database and, most notably, lets you feed it with data from external xml files.

Let's have a look at how things can be done with the help of this framework.

Preparing the test data

Compared to Typemock, using NDbUnit implies a totally different approach to meet our testing needs. So the here described testing scenario requires an instance of an SQL Server database in operation, and it also means that the Entity Framework model that sits on top of this database is completely unaffected.

First things first: For its interactions with the database, NDbUnit relies on a .NET Dataset xsd file. See Step 1 of their Quick Start Guide for a description of how to create one. With this prerequisite in place then, the test fixture's setup code could look something like this:

[TestFixture, TestsOn(typeof(PersonRepository))]     

[Metadata("NDbUnit Quickstart URL",     

          "http://code.google.com/p/ndbunit/wiki/QuickStartGuide")]     

[Description("Uses the NDbUnit library to provide test data to a local database.")]     

public class PersonRepositoryFixture     

{     

    #region Constants     

    private const string XmlSchema = @"..\..\TestData\School.xsd";     

    #endregion // Constants     

    #region Fields     

    private SchoolEntities _schoolContext;     

    private PersonRepository _personRepository;     

    private INDbUnitTest _database;     

    #endregion // Fields     

    #region Setup/TearDown     

    [FixtureSetUp]     

    public void FixtureSetUp()     

    {     

        var connectionString = ConfigurationManager.ConnectionStrings["School_Test"].ConnectionString;     

        _database = new SqlDbUnitTest(connectionString);     

        _database.ReadXmlSchema(XmlSchema);     

        var entityConnectionStringBuilder = new EntityConnectionStringBuilder     

        {     

            Metadata = "res://*/School.csdl|res://*/School.ssdl|res://*/School.msl",     

            Provider = "System.Data.SqlClient",     

            ProviderConnectionString = connectionString     

        };     

        _schoolContext = new SchoolEntities(entityConnectionStringBuilder.ConnectionString);     

        _personRepository = new PersonRepository(this._schoolContext);     

    }     

    [FixtureTearDown]     

    public void FixtureTearDown()     

    {     

        _database.PerformDbOperation(DbOperationFlag.DeleteAll);     

        _schoolContext.Dispose();     

    }     

    ...

As you can see, there is slightly more fixture setup code involved if your tests are using NDbUnit to provide the test data: Because we're dealing with a physical database instance here, we first need to pick up the test-specific connection string from the test assemblies' App.config, then initialize an NDbUnit helper object with this connection along with the provided xsd file, and also set up the SchoolEntities and the PersonRepository instances accordingly.

The _database field (an instance of the INdUnitTest interface) will be our single access point to the underlying database: We use it to perform all the required operations against the data store. To have a flexible mechanism to easily insert data into the database, we can write a helper method like this:

private void InsertTestData(params string[] dataFileNames)     

{     

    _database.PerformDbOperation(DbOperationFlag.DeleteAll);     

    if (dataFileNames == null)     

    {     

        return;     

    }     

    try     

    {     

        foreach (string fileName in dataFileNames)     

        {     

            if (!File.Exists(fileName))     

            {     

                throw new FileNotFoundException(Path.GetFullPath(fileName));     

            }     

            _database.ReadXml(fileName);     

            _database.PerformDbOperation(DbOperationFlag.InsertIdentity);     

        }     

    }     

    catch     

    {     

        _database.PerformDbOperation(DbOperationFlag.DeleteAll);     

        throw;     

    }     

}

This lets us easily insert test data from xml files, in any number and in a controlled order (which is important because we eventually must fulfill referential constraints, or we must account for some other stuff that imposes a specific ordering on data insertion). Again, as with Typemock, I won't go into API details here. - Unfortunately, there isn't too much documentation for NDbUnit anyway, other than the already mentioned Quick Start Guide (and the source code itself, of course) - a not so uncommon problem with smaller Open Source Projects.

Last not least, we need to provide the required test data in xml form. A snippet for data from the People table might look like this, for example:

<?xml version="1.0" encoding="utf-8" ?>     

<School xmlns="http://tempuri.org/School.xsd">     

  <Person>     

    <PersonID>1</PersonID>     

    <LastName>Abercrombie</LastName>     

    <FirstName>Kim</FirstName>     

    <HireDate>1995-03-11T00:00:00</HireDate>     

  </Person>     

  <Person>     

    <PersonID>2</PersonID>     

    <LastName>Barzdukas</LastName>     

    <FirstName>Gytis</FirstName>     

    <EnrollmentDate>2005-09-01T00:00:00</EnrollmentDate>     

  </Person>     

  <Person>     

    ...

You can also have data from various tables in one single xml file, if that's appropriate for you (but beware of the already mentioned ordering issues). It's true that your test assembly may end up with dozens of such xml files, each containing quite a big amount of text data. But because the files are of very low complexity, and with the help of a little bit of Copy/Paste and Excel magic, this appears to be well manageable.

Executing some basic tests

Here are some of the possible tests that can be written with the above preparations in place:

private const string People = @"..\..\TestData\School.People.xml";     

...     

[Test, MultipleAsserts, TestsOn("PersonRepository.GetNameList")]     

public void GetNameList_ListOrdering_ReturnsTheExpectedFullNames()     

{     

    InsertTestData(People);     

    List<string> names =     

        _personRepository.GetNameList(NameOrdering.List);     

    Assert.Count(34, names);     

    Assert.AreEqual("Abercrombie, Kim", names.First());     

    Assert.AreEqual("Zheng, Roger", names.Last());     

}     

[Test, MultipleAsserts, TestsOn("PersonRepository.GetNameList")]     

[DependsOn("RemovePerson_CalledOnce_DecreasesCountByOne")]     

public void GetNameList_NormalOrdering_ReturnsTheExpectedFullNames()     

{     

    InsertTestData(People);     

    List<string> names =     

        _personRepository.GetNameList(NameOrdering.Normal);     

    Assert.Count(34, names);     

    Assert.AreEqual("Alexandra Walker", names.First());     

    Assert.AreEqual("Yan Li", names.Last());     

}     

[Test, TestsOn("PersonRepository.AddPerson")]     

public void AddPerson_CalledOnce_IncreasesCountByOne()     

{     

    InsertTestData(People);     

    int count = _personRepository.Count;     

    _personRepository.AddPerson(new Person { FirstName = "Thomas", LastName = "Weller" });     

    Assert.AreEqual(count + 1, _personRepository.Count);     

}     

[Test, TestsOn("PersonRepository.RemovePerson")]     

public void RemovePerson_CalledOnce_DecreasesCountByOne()     

{     

    InsertTestData(People);     

    int count = _personRepository.Count;     

    _personRepository.RemovePerson(new Person { PersonID = 33 });     

    Assert.AreEqual(count - 1, _personRepository.Count);     

}

Not much difference here compared to the corresponding Typemock versions, except that we had to do a bit more preparational work (and also it was harder to get the required knowledge). But this picture changes quite dramatically if we look at some more demanding test cases:

Ok, and what if things are becoming somewhat more complex?

Tests like the above ones represent the 'easy' scenarios. They may account for the biggest portion of real-world use cases of the application, and they are important to make sure that it is generally sound. But usually, all these nasty little bugs originate from the more complex parts of our code, or they occur when something goes wrong.

So, for a testing strategy to be of real practical use, it is especially important to see how easy or difficult it is to mimick a scenario which represents a more complex or exceptional case. The following test, for example, deals with the case that there is some sort of invalid input from the caller:

[Test, MultipleAsserts, TestsOn("PersonRepository.GetCourseMembers")]     

[Row(null, typeof(ArgumentNullException))]     

[Row("", typeof(ArgumentException))]     

[Row("NotExistingCourse", typeof(ArgumentException))]     

public void GetCourseMembers_WithGivenVariousInvalidValues_Throws(string courseTitle, Type expectedInnerExceptionType)     

{     

    var exception = Assert.Throws<RepositoryException>(() =>     

                                _personRepository.GetCourseMembers(courseTitle));     

    Assert.IsInstanceOfType(expectedInnerExceptionType, exception.InnerException);     

}

Apparently, this test doesn't need an 'Arrange' part at all (see here for the same test with the Typemock tool). It acts just like any other client code, and all the required business logic comes from the database itself. This doesn't always necessarily mean that there is less complexity, but only that the complexity happens in a different part of your test resources (in the xml files namely, where you sometimes have to spend a lot of effort for carefully preparing the required test data).

Another example, which relies on an underlying 1-n relationship, might be this:

[Test, MultipleAsserts, TestsOn("PersonRepository.GetCourseMembers")]     

public void GetCourseMembers_WhenGivenAnExistingCourse_ReturnsListOfStudents()     

{     

    InsertTestData(People, Course, Department, StudentGrade);     

    List<Person> persons = _personRepository.GetCourseMembers("Macroeconomics");     

    Assert.Count(4, persons);     

    Assert.ForAll(     

        persons,     

        @p => new[] { 10, 11, 12, 14 }.Contains(@p.PersonID),     

        "Person has none of the expected IDs.");     

}

If you compare this test to its corresponding Typemock version, you immediately see that the test itself is much simpler, easier to read, and thus much more intention-revealing. The complexity here lies hidden behind the call to the InsertTestData() helper method and the content of the used xml files with the test data. And also note that you might have to provide additional data which are not even directly relevant to your test, but are required only to fulfill some integrity needs of the underlying database.

Conclusion

The first thing to notice when comparing the NDbUnit approach to its Typemock counterpart obviously deals with performance: Of course, NDbUnit is much slower than Typemock. Technically, it doesn't even make sense to compare the two tools. But practically, it may well play a role and could or could not be an issue, depending on how much tests you have of this kind, how often you run them, and what role they play in your development cycle.

Also, because the dataset from the required xsd file must fully match the database schema (even in parts that otherwise wouldn't be relevant to you), it can be quite cumbersome to be in a team where different people are working with the database in parallel.

My personal experience is – as already said in the first part – that Typemock gives you a better development experience in a 'dynamic' scenario (when you're working in some kind of TDD-style, you're oftentimes executing the tests from your dev box, and your database schema changes frequently), whereas the NDbUnit approach is a good and solid solution in more 'static' development scenarios (when you need to execute the tests less frequently or only on a separate build server, and/or the underlying database schema can be kept relatively stable), for example some variations of higher-level integration or User-Acceptance tests.

But in any case, opening Entity Framework based applications for testing requires a fair amount of resources, planning, and preparational work – it's definitely not the kind of stuff that you would call 'easy to test'. Hopefully, future versions of EF will take testing concerns into account. Otherwise, I don't see too much of a future for the framework in the long run, even though it's quite popular at the moment...

The sample solution

A sample solution (VS 2010) with the code from this article series is available via my Bitbucket account from here (Bitbucket is a hosting site for Mercurial repositories. The repositories may also be accessed with the Git and Subversion SCMs - consult the documentation for details. In addition, it is possible to download the solution simply as a zipped archive – via the 'get source' button on the very right.). The solution contains some more tests against the PersonRepository class, which are not shown here. Also, it contains database scripts to create and fill the School sample database.

To compile and run, the solution expects the Gallio/MbUnit framework to be installed (which is free and can be downloaded from here), the NDbUnit framework (which is also free and can be downloaded from here), and the Typemock Isolator tool (a fully functional 30day-trial is available here). Moreover, you will need an instance of the Microsoft SQL Server DBMS, and you will have to adapt the connection strings in the test projects App.config files accordingly.

Testing Entity Framework applications, pt. 2: Typemock

Thomas Weller — Tue, 08 Nov 2011 06:27:34 GMT

Originally posted on: http://geekswithblogs.net/thomasweller/archive/2011/11/08/testing-entity-framework-applications-pt.-2-typemock.aspx

This is the second of a three part series that deals with the issue of faking test data in the context of a legacy app that was built with Microsoft's Entity Framework (EF) on top of an MS SQL Server database – a scenario that can be found very often. Please read the first part for a description of the sample application, a discussion of some general aspects of unit testing in a database context, and of some more specific aspects of the here discussed EF/MSSQL combination.

Lately, I wondered how you would ‘mock’ the data layer of a legacy application, when this data layer is made up of an MS Entity Framework (EF) model in team with a MS SQL Server database. The question originally came up in the context of how you could enable higher-level integration tests (automated UI tests, to be exact) for a legacy application that uses this EF/MSSQL combo as its data store mechanism – a not so uncommon scenario.

The question sparked my interest, so I decided to dive into it a bit deeper. What I've found out is, in short, that it's not very easy and straightforward to do it – but it can be done. The two strategies that are best suited to fit the bill involve using either the (commercial) Typemock Isolator tool or the (free) NDbUnit framework. This post will present the Typemock approach...

When it comes to mocking and faking, Typemock is something like the swiss army knife in a tester's toolbelt. It's functionally comparable to MS Moles, in that there aren't any limits in what it can do (it's really Mocking the Unmockable). You can easily write all kinds of test doubles for components that you otherwise could not fake: Static classes, Framework classes, Sealed classes, Non-virtual members and so on... The big difference to Moles however is that Typemock has a well-crafted API and generally is so much easier to handle, understand, learn, and remember that this alone would justify the price difference.

Preparing the test data

As I have shown in the first part, the PersonRepository expects an instance of EF's ObjectContext class in its c'tor. This project-specific class is generated by the EF designer and contains, among (too) many other things, the conceptual entity model which is derived from the underlying database. (It's called SchoolEntities in our case.)

This marks the point where we can plug in the Typemock Isolator tool to isolate the system from the underlying database, faking the ObjectContext and thus having the opportunity to feed the PersonRepository class with self-provided data on a per-test basis as required.

The test fixture's Setup code will look like this, when using this approach:

[TestFixture, TestsOn(typeof(PersonRepository))]     

[Description("Uses Typemock Isolator 2010 to fake the data for the applications EF data model. " +     

             "Trial version can be downloaded from here: http://www.typemock.com/typemock-isolator-product3/")]     

public class PersonRepositoryFixture     

{     

    #region Fields     

    private SchoolEntities _schoolContext;     

    private PersonRepository _personRepository;     

    #endregion // Fields     

    #region Setup/TearDown     

    [SetUp]     

    public void SetUp()     

    {     

        _schoolContext = Isolate.Fake.Instance<SchoolEntities>();     

        _personRepository = new PersonRepository(_schoolContext);     

    }     

    ...

Note that we've altered only one single line of code here, compared to the 'original' version from the previous part: The _schoolContext field is initialized with a Fake instance of the SchoolEntities class instead of the 'real' object (see here for a short clarification of the sometimes confusing terminology around mocks, fakes, stubs and the like).

What does it mean? Well, it means that our _schoolContext field actually references a true instance of the SchoolEntities class, and not some sort of proxy object. You can call all methods and properties on it, they will do nothing by default and will return the respective default value for value types, or another Fake instance for reference types - unless we explicitely tell Typemock to return some custom, pre-defined values for us (or call some custom code on our behalf). And that's exactly what we need here to isolate the system under test from its EF data model (and its database, consequently).

To accomplish this, we first define a helper class to hold the test data that we will use (and also mimick other required database properties like e.g. referential constraints). It will act as a kind of 'in-memory database':

static class FakeDataHolder     

{     

    #region Fields     

    // The xxxData collections serve as an internal cache. They represent the database,     

    // are filled during construction  and not altered thereafter.     

    private static readonly ReadOnlyCollection<Person> PersonData;     

    private static readonly ReadOnlyCollection<OfficeAssignment> OfficeAssignmentData;     

    // The xxxList collections mirror the xxxData collections. They represent a working copy of the data,     

    // which is exposed through properties to the outside and can be reset via the 'Reset()' method.     

    private static readonly List<Person> PersonList = new List<Person>();     

    private static readonly List<OfficeAssignment> OfficeAssignmentList = new List<OfficeAssignment>();     

    #endregion // Fields     

    #region Properties     

    public static IQueryable<Person> Persons     

    {     

        get { return PersonList.AsQueryable(); }     

    }     

    public static IQueryable<OfficeAssignment> OfficeAssignments     

    {     

        get { return OfficeAssignmentList.AsQueryable(); }     

    }     

    #endregion // Properties     

    #region Construction     

    static FakeDataHolder()     

    {  

        PersonData = new List<Person>     

            {     

                new Person {PersonID = 1, FirstName = "Kim", LastName = "Abercrombie"},     

                new Person {PersonID = 2, FirstName = "Gytis", LastName = "Barzdukas"},     

                new Person {PersonID = 3, FirstName = "Peggy", LastName = "Justice"},     

                new Person {PersonID = 4, FirstName = "Fadi", LastName = "Fakhouri"},     

                new Person {PersonID = 5, FirstName = "Roger", LastName = "Harui"},     

                new Person {PersonID = 6, FirstName = "Yan", LastName = "Li"},     

                new Person {PersonID = 7, FirstName = "Laura", LastName = "Norman"},     

                new Person {PersonID = 8, FirstName = "Nino", LastName = "Olivotto"},     

                new Person {PersonID = 9, FirstName = "Wayne", LastName = "Tang"},     

                new Person {PersonID = 10, FirstName = "Meredith", LastName = "Alonso"},     

                new Person {PersonID = 11, FirstName = "Sophia", LastName = "Lopez"},     

                new Person {PersonID = 12, FirstName = "Meredith", LastName = "Browning"},     

                new Person {PersonID = 13, FirstName = "Arturo", LastName = "Anand"},     

                new Person {PersonID = 14, FirstName = "Alexandra", LastName = "Walker"},     

                new Person {PersonID = 15, FirstName = "Carson", LastName = "Powell"},     

                new Person {PersonID = 16, FirstName = "Damien", LastName = "Jai"},     

                new Person {PersonID = 17, FirstName = "Robyn", LastName = "Carlson"},     

                new Person {PersonID = 18, FirstName = "Roger", LastName = "Zheng"},     

                new Person {PersonID = 19, FirstName = "Carson", LastName = "Bryant"},     

                new Person {PersonID = 20, FirstName = "Robyn", LastName = "Suarez"},     

                new Person {PersonID = 21, FirstName = "Roger", LastName = "Holt"},     

                new Person {PersonID = 22, FirstName = "Carson", LastName = "Alexander"},     

                new Person {PersonID = 23, FirstName = "Isaiah", LastName = "Morgan"},     

                new Person {PersonID = 24, FirstName = "Randall", LastName = "Martin"},     

                new Person {PersonID = 25, FirstName = "Candace", LastName = "Kapoor"},     

                new Person {PersonID = 26, FirstName = "Cody", LastName = "Rogers"},     

                new Person {PersonID = 27, FirstName = "Stacy", LastName = "Serrano"},     

                new Person {PersonID = 28, FirstName = "Anthony", LastName = "White"},     

                new Person {PersonID = 29, FirstName = "Rachel", LastName = "Griffin"},     

                new Person {PersonID = 30, FirstName = "Alicia", LastName = "Shan"},     

                new Person {PersonID = 31, FirstName = "Jasmine", LastName = "Stewart"},     

                new Person {PersonID = 32, FirstName = "Kristen", LastName = "Xu"},     

                new Person {PersonID = 33, FirstName = "Erica", LastName = "Gao"},     

                new Person {PersonID = 34, FirstName = "Roger", LastName = "Van Houten"}     

            }     

            .AsReadOnly();  

        OfficeAssignmentData = new List<OfficeAssignment>     

            {     

                new OfficeAssignment { InstructorID = 18, Location = "143 Smith" }     

            }     

            .AsReadOnly();     

    }     

    #endregion // Construction     

    #region Operations     

    public static void Reset()     

    {     

        PersonList.Clear();     

        PersonList.AddRange(PersonData);     

        OfficeAssignmentList.Clear();     

        OfficeAssignmentList.AddRange(OfficeAssignmentData);     

    }     

    public static void AddPerson(Person person)     

    {     

        PersonList.Add(person);     

    }     

    public static void DeletePerson(Person person)     

    {     

        if (OfficeAssignmentList.Any(@a => @a.InstructorID == person.PersonID))     

        {     

            throw new InvalidOperationException("FK_OfficeAssignment_Person");     

        }     

        PersonList.Remove(person);     

    }     

    #endregion // Operations     

} // class FakedataHolder

The second step then would be to make our test fixture's _schoolContext field return these values (or call the appropriate FakeDataHolder methods, respectively). For this purpose, we can declare a helper method like this in the PersonRepositoryFixture class:

private void FakeData()     

{     

    FakeDataHolder.Reset();  

    Isolate.WhenCalled(() => _schoolContext.People)  

           .WillReturnCollectionValuesOf(FakeDataHolder.Persons);     

    Isolate.WhenCalled(() => _schoolContext.People.AddObject(null))     

           .DoInstead(@ctx => FakeDataHolder.AddPerson(@ctx.Parameters[0] as Person));     

    Isolate.WhenCalled(() => _schoolContext.People.DeleteObject(null))     

           .DoInstead(@ctx => FakeDataHolder.DeletePerson(@ctx.Parameters[0] as Person));     

}

I won't go into the details of Typemock's API syntax here (you may consult the Online Documentation for this, if you are interested), but generally I like it because it's very easy to read and understand without oversimplifying things. Or, in other words: I don't have to explain much here, the code itself tells it all...

Executing some basic tests

Here are some of the possible tests that can be written with the above preparations in place:

[Test, Isolated, MultipleAsserts, TestsOn("PersonRepository.GetNameList")]     

public void GetNameList_ListOrdering_ReturnsTheExpectedFullNames()     

{     

    FakeData();     

    List<string> names =     

        _personRepository.GetNameList(NameOrdering.List);     

    Assert.Count(34, names);     

    Assert.AreEqual("Abercrombie, Kim", names.First());     

    Assert.AreEqual("Zheng, Roger", names.Last());     

}     

[Test, MultipleAsserts, TestsOn("PersonRepository.GetNameList")]     

public void GetNameList_NormalOrdering_ReturnsTheExpectedFullNames()     

{     

    FakeData();     

    List<string> names =     

        _personRepository.GetNameList(NameOrdering.Normal);     

    Assert.Count(34, names);     

    Assert.AreEqual("Alexandra Walker", names.First());     

    Assert.AreEqual("Yan Li", names.Last());     

}     

[Test, Isolated, TestsOn("PersonRepository.AddPerson")]     

public void AddPerson_CalledOnce_IncreasesCountByOne()     

{     

    FakeData();     

    int count = _personRepository.Count;     

    _personRepository.AddPerson(new Person { FirstName = "Thomas", LastName = "Weller" });     

    Assert.AreEqual(count + 1, _personRepository.Count);     

}     

[Test, Isolated, TestsOn("PersonRepository.RemovePerson")]     

public void RemovePerson_CalledOnce_DecreasesCountByOne()     

{     

    FakeData();     

    int count = _personRepository.Count;     

    _personRepository.RemovePerson(new Person { PersonID = 33 });     

    Assert.AreEqual(count - 1, _personRepository.Count);     

}     

[Test, Isolated, TestsOn("PersonRepository.RemovePerson")]     

public void RemovePerson_ForWhomAnOfficeAssignmentExists_Throws()     

{     

    FakeData();     

    Assert.Throws<RepositoryException>(() =>     

        _personRepository.RemovePerson(new Person { PersonID = 18 }));     

}

I kept these tests deliberately simple to underpin the fact that Typemock-based tests don't need to be much different from non-faked tests, and also to make them comparable to the other options that are discussed here (the NDbUnit approach and the non-faked version, running your tests directly against a real instance of MS SQL Server, namely).

But wait, what if things are becoming somewhat more complex?

Admittedly (and intentionally), the above tests cover only some very simple test cases. This may be enough for some of your test scenarios: the 'normal' use cases, which may make up something well above 95% of what your application effectively is doing in production ("it just works"), but is easily covered with a few simple tests. The more interesting and important bits are the exceptional situations; the corner cases, where something unexpected happens. This is what consumes most of the time and effort in software development: To make an application robust and stable, and make it react in a predictable, user-friendly way even under exceptional circumstances.

In such a situation (i.e. if you want to simulate some sort of exceptional condition), chances are that you will have to dive deep into the production code - or even some 3rd party code, if it is available - to find out what you will have to return from your fake. A (still very simple) test of this kind could be this, for example:

[Test, Isolated, MultipleAsserts, TestsOn("PersonRepository.GetCourseMembers")]     

[Row(null, typeof(ArgumentNullException))]     

[Row("", typeof(ArgumentException))]     

[Row("NotExistingCourse", typeof(ArgumentException))]     

public void GetCourseMembers_WhenGivenVariousInvalidValues_Throws(string courseTitle, Type expectedInnerExceptionType)     

{     

    // Generally return false from the expression '_schoolContext.Courses.Any(...)'     

    Isolate.WhenCalled(() => _schoolContext.Courses.Any(null))     

           .WillReturn(false);     

    var exception = Assert.Throws<RepositoryException>(() =>     

                                _personRepository.GetCourseMembers(courseTitle));     

    Assert.IsInstanceOfType(expectedInnerExceptionType, exception.InnerException);     

}

This looks quite trivial, but it took me some minutes to understand that it's the Any() extension method that I had to fake here, and I also had to slightly refactor the FakeDataHolder() helper class to make this work. All in all, not too big a deal, you may say. True, but keep in mind that small things like that can easily add up to a huge amount of additional work (that your manager might not be willing to pay for)...

The other situation in which using Typemock becomes somewhat more laborious is when you have to perform a lot of preparational work of the above described kind to simulate a regular scenario, which you would otherwise (when running against a real database) just take for granted, without thinking much about it. Look at this test, for example:

[Test, Isolated, MultipleAsserts, TestsOn("PersonRepository.GetCourseMembers")]     

public void GetCourseMembers_WhenGivenAnExistingCourse_ReturnsListOfStudents()     

{     

    // Avoid the ArgumentNullException     

    Isolate.WhenCalled(() => _schoolContext.Courses.Any(null))     

           .WillReturn(true);     

    // Always return true from the expression 'Person.StudentGrades.Any(...)'     

    var fakePerson = Isolate.Fake.Instance<Person>();     

    Isolate.WhenCalled(() => fakePerson.StudentGrades.Any(null))     

           .WillReturn(true);     

    Isolate.Swap.AllInstances<Person>()     

           .With(fakePerson);     

    // Return the expected list of persons     

    Isolate.WhenCalled(() => _schoolContext.People)     

           .WillReturnCollectionValuesOf(new List<Person>     

                                            {     

                                                new Person {PersonID = 9, FirstName = "Wayne", LastName = "Tang"},     

                                                new Person {PersonID = 10, FirstName = "Meredith", LastName = "Alonso"},     

                                                new Person {PersonID = 11, FirstName = "Sophia", LastName = "Lopez"},     

                                                new Person {PersonID = 12, FirstName = "Meredith", LastName = "Browning"},     

                                                new Person {PersonID = 14, FirstName = "Alexandra", LastName = "Walker"},     

                                                new Person {PersonID = 22, FirstName = "Carson", LastName = "Alexander"}     

                                            }     

                                            .AsQueryable());     

    List<Person> persons = _personRepository.GetCourseMembers("Macroeconomics");     

    Assert.Count(6, persons);     

    Assert.ForAll(     

        persons,     

        @p => new[] { 9, 10, 11, 12, 14, 22 }.Contains(@p.PersonID),     

        "Person has none of the expected IDs.");     

}

The test asserts that, when asking for the members of a specific course, we actually are provided with the expected list, if we have set up the underlying ObjectContext fake to return the correct data. (One word about the Isolate.Swap.AllInstances() expression here: It instructs Typemock to replace all future instances of the Person class with the here defined fakePerson object, whenever the code under test should create a new Person instance.) See how the 'Arrange' part of the test blows up and also requires quite some intimate knowledge about the code under test, in order to provide the required return values (I've heard this once being called Wishful mocking...)?

Sometimes, especially when dealing with a legacy codebase that you cannot change, this is the only option at all to put such code under test, but it easily can mean that you will have to do a lot of work, if you will have to account for all kinds of database relations, triggers, check constraints, stored procedures and stuff like that. How much, will largely depend on the complexity of the underlying database (and of course also on the complexity of the code under test)...

Conclusion

Typemock is a powerful and flexible tool to handle the here described EF/MSSQL scenario. It's blazingly fast, fully isolates your system under test from any external data source, and lets you quickly and easily adapt/refactor your test code if you need to. All your test data are defined directly in the test code, so chances are high that you get immediate feedback in form of a compiler error when you have changed your database schema (and consequently the EF conceptual model) for some reason.

The downsides are more practical in nature: As I illustrated above, it can be a lot of work to fake certain scenarios with Typemock, so be prepared that it may not always be straightforward and easy to author tests with the help of the tool (but there will be a rich reward for your efforts...). Also, Typemock is a commercial tool,which means that it does not come for free in financial terms. You will have to make the explicit decision at some point whether it's worth its price in your specific situation or not.

Whereas this part of the article series has shown how the Typemock Isolator tool can be used to deal with a scenario where an application sits on top of an MS Entity Framework class model, the next part will accomplish the same with the NDbUnit framework.

The sample solution

Testing Entity Framework applications, pt. 1

Thomas Weller — Sun, 06 Nov 2011 09:25:07 GMT

Originally posted on: http://geekswithblogs.net/thomasweller/archive/2011/11/06/testing-entity-framework-applications-pt.-1.aspx

For good or bad, Microsoft’s Entity Framework (EF) has become one of the most widely used ORM tools out there. While some may state that it's not among the better ones (or that it's not even a real ORM), it’s definitely the most convenient one: its Visual Studio integration and consequently its integration with the MS SQL Server database is unparalleled. This is especially relevant to people who haven’t used the concept of object-relational mapping before - there's almost no initial learning curve associated with the framework. While it would theoretically be possible to use EF with a DBMS other than MS SQL Server, it’s in practice almost exclusively used in combination with Microsoft's database engine.

Lately, I wondered how you would ‘mock’ EF’s data model - together with an underlying MSSQL database - in such a scenario. The question arose in the broader context of writing integration tests (automated UI tests, to be exact) for a legacy application which uses the described EF/MSSQL combo as its data store mechanism. It turned out that the possible strategies are not very obvious and require some additional tools and effort...

This is part 1 of a three part series that examines some ways to cope with the above described scenario. While the next two parts are more concerned with concrete implementation details, this part discusses some more general considerations on the issue and introduces the sample application which serves as a 'target' for the tests that will be presented in the latter parts.

Handling the data layer in tests

In general, things tend to become a bit tricky when it comes to testing database-related parts of an application. But how would you go for database testing? is an often heard question from people who are new to unit testing. For good reasons, because database related testing is one of the more demanding areas in the testing field, mainly because of two aspects:

There’s not a single, easy-to-use framework to test the database in complete isolation – no matter what DBMS you use.
More often than not, the business logic of the application is partly implemented by the application's data access code, and partly by the database itself (e.g. through stored procs, triggers, constraints etc.).

Moreover, if we take a closer look at the question (How would you go for database testing?), it becomes clear that, effectively, we're talking about two different scenarios here:

Actually testing the data layer of a project.
Stubbing out the data layer to enable other (integration-style) tests.

Testing the data layer

The best way to test an application’s data store mechanism is to test it in team with the data access code that sits on top of it. Usually, your test code will access the production code which is closest to the database in such a case. Roy Osherove, in his book The Art Of Unit Testing, has the following to say about it:

I usually write integration-style tests for the data layer (the part of the app structure that talks directly to the database) in my applications because data logic is almost always divided between the application logic and the database itself (triggers, security rules, referential integrity, and so on). […], the only way to make sure it works in tests is to couple testing the data-layer logic to the real database. (p. 277)

For a project with EF, you would write tests against the EF data model, thus acting as a data model client. The underlying database could be kept constant in such a scenario for example by wrapping each test in a database transaction, or by resetting the entire database at the required points – either by running some scripts or by using the DB server's backup/restore mechanism.

I won't go into more details here because, as described above, it's the second scenario which served as a starting point for this article series:

Stubbing out the data layer

Besides the necessity to test an application's data layer directly, we also need a way to simulate the entire data access functionality of an application in order to run other kinds of (integration-style) tests that somehow rely on the data access part, without actually testing it.

If your application architecture is made up along the lines of Domain-driven design, the general layer architecture might look roughly like this:

Note that this is only one out of many possible architectures, and it's in no way mandatory for using the tools and techniques which are presented here.

The important piece is that you have some client code against that you want to write tests, and that there is an EF data model somewhere down the chain.

(Note: the 'client' here actually is the Repository, and Client code could be anything that calls it. The diagram admittedly is somewhat misleading in that respect...)

Such tests could be for example integration tests against an application's Business Logic layer, or some User Acceptance Tests on the UI level, involving a UI automation framework like e.g. WatiN, Selenium, or White.

Also, you could use any DBMS that works with EF (here's a list). The basic story remains the same...

Special issues with MS Entity Framework

Writing tests against code that invokes EF is not easy – obviously, the Testing issue wasn't a concern at all when developing the framework. The two biggest stumbling blocks on the way to writing tests are:

EF stores the used data provider type in its mapping file (*.edmx), which in turn is compiled as an embedded resource into the respective assembly. In consequence this means: The specification of the DBMS technology is part of the application code and cannot be changed later. So there's no way to replace the underlying database with an embedded one like SQLite or SQL Server CE. You only can alter the location of the used database, but you have to stick to the once chosen database type.
EF does not adhere to the standards of Interface-based programming. There are abstract classes, sealed classes, and classes with non-public constructors everywhere – but not a single interface. This means that using one of the free mocking frameworks like e.g. Moq, fakeiteasy, or NMock is also not an option.

The different approaches

The above outlined restrictions leave us with these options (at least these are the ones that came to my mind):

We have a 'static' database in place and wrap each test into a database transaction, or
we mock (or fake) the EF code directly, using the (commercial) Typemock Isolator tool, or
we set up a dedicated instance of the SQL Server database and feed it with the required test data via the NDbUnit library.

Regarding the first strategy, I won't discuss it here in depth (note however that it is included with the sample solution – see the CourseManager.Test.MsSqlServer project), because this article series is more about mocking test data, whereas this approach uses a predefined set of data. Of course, you could extend it in various ways to cope with specific needs, but this would be a different story. I'd only like to mention here that this approach could bring its own set of problems:

You're writing the tests against a fixed set of data, which makes this approach somewhat inflexible and sometimes may even prevent you from covering a specific scenario (of course there are various ways to cope with such a situation, but they are not easily implemented and require quite some additional effort).
Because you're heavily using transactions, it's easy to run into specific issues from this side (especially if your test wants to use a transaction of its own, when the entire test method is already wrapped in a transaction).

The other two approaches (Typemock and NDbUnit) are fairly different in how they do things: While the Typemock approach directly intercepts the calls to the EF classes, NDbUnit manipulates the underlying database. In other words, the two approaches act upon different levels of an application's data access system, as shown below:

Also, the two methodologies are not equivalent in terms of what is best in which scenario. We’ll see that in more detail in the next parts, but the bottom line is this:

Typemock is the preferable tool when developing an application or feature, because it's easy to alter a return value, you usually get an immediate compile error if your test code is not in sync with the database schema, and it's lightning fast, because there is no disk I/O whatsoever involved. The biggest drawback of Typemock is the fact that things easily become very expensive and hard to maintain when you have to fake things like referential integrity constraints and/or a massive amount of data.
NDbUnit on the other hand shines when writing tests against a relatively stable database schema, having a huge amount of data, or when you are heavily concerned with referential integrity constraints and their interrelations. It lets you declare all of your test data in external xml files, which then can be loaded on a per-test basis. The most prominent downside here lies in the framework's lacking robustness against schema changes: If there are any error messages, then you will get them only during runtime, and chances are big that the error messages will not directly point you to the underlying error.

The sample target application: Course Manager

We start with the Course Manager sample application as taken from the MSDN Quickstart. It’s a very simple EF app with only the bare minimum:

a database (‘School’)
an EF data model on top of the School database
a form to display/edit these data

Here's a screenshot:

In this very simple app, the form then is the client of the data model.

The data connection

The connection string for the application's database is defined in the App.config. The EF connection string entirely contains the normal MS SQL Server connection string, so you may easily modify name and location of the underlying database (but – as pointed out above – you cannot change the type of the provider). The App.config looks like this:

<?xml version="1.0" encoding="utf-8"?>

<configuration>

  <connectionStrings>

    <add name="SchoolEntities"

         connectionString="metadata=res://*/School.csdl|res://*/School.ssdl|res://*/School.msl;provider=System.Data.SqlClient;provider connection string=&quot;Data Source=<server instance name>;Initial Catalog=School;Integrated Security=True;Pooling=False;MultipleActiveResultSets=True&quot;" providerName="System.Data.EntityClient" />

  </connectionStrings>

</configuration>

Adding some ‘meat’ to the target

In theory this would be enough to demonstrate the approach: We could write UI tests against the form while stubbing out the database – in fact this would be very close to what might happen in real development practice. But because UI tests are a quite demanding issue in itself and require at least some additional testing framework (and thus would introduce further complexity), I modified/extended the original solution to have a separate data access layer with a simple repository. This resulted in the assembly CourseManager.Data, which looks like this:

As you can see, I added a PersonRepository class, which acts as our sample client for the EF data model. This will be the class that we’ll write our tests against (Again: It could also be any other code which sits on top of an EF data model.).

General code and fixture layout

Entity Framework encapsulates its entire database stuff as well as all data entities from the conceptual model in one single class which derives from the ObjectContext base class. This is a horrible complex and far too long beast, and it's doing way too much different things (in other words: there's absolutely no Separation of concerns). The EF designer combines this base class with the conceptual model from our School database and generates a SchoolEntities class for us, which serves as our single access point to the database. Consequently, our sample repository class (PersonRepository), which is there to encapsulate all the concrete data access code from the rest of the application, gets an instance of this SchoolEntities class via its c'tor (This is an example for Dependency Injection, a coding technique which is generally very recommendable to write clean, maintainable code, and is invaluable if you want to design your code for testability.)

So the first part of our test fixture for the PersonRepository class will be this (using Gallio):

[TestFixture, TestsOn(typeof(PersonRepository))]     

[Metadata("MSDN Entity Framework Quickstart URL",     

          "http://msdn.microsoft.com/en-us/library/bb399182.aspx")]     

[Description("Tests against the 'School' database as it is provided by MS. " +     

             "This expects the 'School' database from the quickstart sample.")]     

public class PersonRepositoryFixture     

{     

    #region Fields     

    private SchoolEntities _schoolContext;     

    private PersonRepository _personRepository;     

    #endregion // Fields     

    #region Setup/TearDown     

    [SetUp]     

    public void SetUp()     

    {     

        _schoolContext = new SchoolEntities();     

        _personRepository = new PersonRepository(_schoolContext);     

    }     

    ...

Here, we declare an instance of the PersonRepository class, and we initialize it with a SchoolEntities object. By using a Setup method, we do this initalization for each single test. - Because the ObjectContext is a highly stateful class (for example, it holds a cache with all the already loaded entities), and we want to make sure that our test outcomes are not influenced by previous operations.

And finally: the first test

To make things a little bit more interesting, I also extended the Person entity to have a GetFullName() method which returns the full name of the Person according to the provided nameOrdering argument:

public partial class Person

    public string GetFullName(NameOrdering nameOrdering)

        switch (nameOrdering)

        case NameOrdering.Normal:

            return String.Format("{0} {1}", _FirstName, _LastName);

        case NameOrdering.List:

            return String.Format("{0}, {1}", _LastName, _FirstName);

        default:

            throw new InvalidEnumArgumentException("nameOrdering", (int)nameOrdering, typeof(NameOrdering));

Consequently, the PersonRepository class has a corresponding method GetNameList(), which returns an alphabetically sorted list of these Person names:

public List<string> GetNameList(NameOrdering nameOrdering)     

{     

    try     

    {     

        var fullNames =  new List<string>(     

            _entities.People     

                     .ToList()     

                     .Select(@p => @p.GetFullName(nameOrdering)));     

       fullNames.Sort();     

       return fullNames;     

    }     

    catch (Exception exception)     

    {     

        throw new RepositoryException("Error getting person names.", exception);     

    }     

}

And finally, the tests for GetNameList() look like this then:

[Test, MultipleAsserts, TestsOn("PersonRepository.GetNameList")]     

public void GetNameList_ListOrdering_ReturnsTheExpectedFullNames()     

{     

    List<string> names =     

        _personRepository.GetNameList(NameOrdering.List);     

    Assert.Count(34, names);     

    Assert.AreEqual("Abercrombie, Kim", names.First());     

    Assert.AreEqual("Zheng, Roger", names.Last());     

}     

[Test, MultipleAsserts, TestsOn("PersonRepository.GetNameList")]     

public void GetNameList_NormalOrdering_ReturnsTheExpectedFullNames()     

{     

    List<string> names =     

        _personRepository.GetNameList(NameOrdering.Normal);     

    Assert.Count(34, names);     

    Assert.AreEqual("Alexandra Walker", names.First());     

    Assert.AreEqual("Yan Li", names.Last());     

}

Nothing complicated or surprising here (in general, tests should always be that simple and 'trivial'): We just know what's in the database and check the repositories' corresponding list to correctly mirror this.

Conclusion

Ok, that's it for now. We've covered a lot of ground to set the stage for the forthcoming parts - maybe too much, but I didn't want to close the first part without presenting a single test ;-).

This first part of the article series introduced the sample application that will be used as a target for our tests, discussed some general aspects of database-related testing, and also presented some of the more specific issues that you will have to handle when dealing with MS Entity Framework. The next two parts then will discuss the here outlined approaches with the Typemock and NDbUnit tools in some more detail, building on top of the here described CourseManager sample application.

The sample solution

Some myths of 'Textbook-TDD', and why they are wrong

Thomas Weller — Mon, 31 Oct 2011 12:44:06 GMT

Originally posted on: http://geekswithblogs.net/thomasweller/archive/2011/10/31/some-myths-of-textbook-tdd-and-why-they-are-wrong.aspx

During the last months, I was (for some reasons that are not related to programming) working for a dev shop where software development was done the 'traditional' way: You just write your application's production code, do it as good as you can, and hopefully it will be good enough and no problems will occur in production (this is HDD: Hope-driven development).

Anyway, after I had finished this contract, I felt the need to review some core aspects of what I think is Test-driven development. And while I was doing this, I noticed that some principles (or dogmas, if you prefer) of TDD - you may read them in books or they might be presented to you in some other way when you're learning about TDD - just don't make no sense to me anymore. This post discusses some of the more prominent things in TDD that I don't buy...

#1: "A not compiling test is a failing test"

Huh? Sorry, but no.

A not compiling test is nothing but defective code that is not accepted by the compiler. And a compiler error has exactly nothing to do with the TDD process – it doesn't tell me anything relevant other than that my code is faulty.

Suppose, for example, that you have the following test:

[Test]     

public void SomeTest()     

{     

    var someClass = new SomeClass();     

    int result = someClass.ReturnSomeValue(8);     

    Assert.AreEqual(8, result);     

}

If you try to compile this without having a skeleton of SomeClass and ReturnSomeValue() in place, then the C# compiler will give you this:

What does it say? Well, it tells you exactly one thing: You're trying to reference a symbol that the compiler cannot resolve. Nothing more. The error could come from everywhere in your code, there's nothing on it that makes it somehow specific to testing. So how could one conclude from this error message that it is (or at least is somehow referring to) a failing test?

To really have a failing test, and not just a compiler error, you need to have the following in place:

public class SomeClass     

{     

    public int ReturnSomeValue(int val)     

    {     

        throw new NotImplementedException();     

    }     

}

If you then run the test again, it will compile and give you something like this:

This is what I'd call a meaningful test outcome: The test actually does execute, but the method under test does not (yet) expose the expected behavior.

In short: It makes sense to have empty member skeletons declared before you write any tests. This doesn't contradict the intention of Test-driven development in any way, because it remains true that you always start with a failing test (it's just that it now 'fails' for the correct reason)...

Apart from this, there's a second argument, which does not relate directly to TDD theory, but more to a C# developer's everyday working experience: A developer is more productive and makes less errors when he has decent IntelliSense support at hand. And there only can be IntelliSense if at least an empty method body exists and is accessible.

#2: "Only test the public members of a class"

Why?

This statement may be viable for a more BDD-based approach and/or for integration-style tests, but for TDD this doesn't make sense to me: If the important functionality of a class is encapsulated in a non-public method, how could it be a problem then to write tests for this method? After all, testing (and especially TDD) is about functionality, not about visibility.

Consider, for example, the following 'production code':

public int DoSomeComplexCalculation(int arg1, int arg2)     

{     

    int temp = DoSomeComplexOperation(arg1, arg2);     

    temp = DoAnotherComplexOperation(temp, arg1, arg2);     

    return DoOneMoreComplexOperation(temp, arg1, arg2);     

}

Nothing unusual here: We have a public method, which exposes some functionality to the outside world, and internally delegates the task to some helper methods. Each of them does its own part of the job, and the calling method is responsible for orchestrating the calls, combining the partial results in a meaningful way, and finally returning the end result to the caller. So far, this is standard .NET programming, often seen and quite trivial.

But if you want to develop such code in a test-driven way and stick to the Test only public members dogma (and of course you don't want to make everything public), then the only test that you could ever write would be of this form:

[Test]     

public void DoSomeComplicatedCalculation_WhenGivenSomeValues_ReturnsExpectedResult()     

{     

    int result = new Calculator().DoSomeComplicatedCalculation(1, 2);  

    Assert.AreEqual(3, result, "Calculation does not yield the expected result.");     

}

Let's be honest: Would that be enough for you to develop correct and robust implementations for DoSomeComplexOperation(), DoAnotherComplexOperation(), and DoOneMoreComplexOperation(), when these helper methods in themselves have to perform quite complicated operations? And you will be sure that you've covered all relevant corner cases? Well, then you're a better programmer than me (and possibly also better than the overwhelming majority of all the other developers out there)...

Because I'm not so enlightened, I need to write quite some more test code to make sure that the production code is of high quality and (at least to my knowledge and skills) error-free. Ideally, I will do this:

Make the non-public methods accessible to the test assembly by declaring them as internal and giving the test assembly access rights via the InternalsVisibleTo attribute.
Write some data-driven tests against these internal methods, covering all possible corner cases.
Write an interaction-based test against the public method, to make sure that it is orchestrating the internal methods (that perform the actual calculation) as intended.

A typical test fixture of this kind then could be similar to this (using the Gallio framework for the tests and Typemock Isolator to verify method interactions):

[TestFixture, TestsOn(typeof(Calculator))]     

public class CalculatorFixture     

{     

    [Test, TestsOn("DoSomeComplexOperation")]     

    [Row(1, 2, -1)]     

    [Row(11, 2, 9)]     

    [Row(100, 100, 0)]     

    [Row(int.MaxValue, int.MinValue, -1)]     

    [Row(int.MinValue, int.MinValue, 0)]     

    public void DoSomeComplexOperation_ReturnsExpectedResult(int arg1, int arg2, int expectedResult)     

    {     

        int result = new Calculator().DoSomeComplexOperation(arg1, arg2);     

        Assert.AreEqual(expectedResult, result, "'DoSomeComplexOperation()' does not yield the expected result.");     

    }     

    [Test, TestsOn("DoAnotherComplexOperation")]     

    [Row(1, 2, 3, 1)]     

    [Row(0, 0, 123456, 0)]     

    [Row(-1, 1, 3, 0)]     

    [Row(8, -3, 4, 1)]     

    [Row(1, 1, 0, 999999, ExpectedException = typeof(DivideByZeroException))]     

    public void DoAnotherComplexOperation_ReturnsExpectedResult(int temp, int arg1, int arg2, int expectedResult)     

    {     

        int result = new Calculator().DoAnotherComplexOperation(temp, arg1, arg2);     

        Assert.AreEqual(expectedResult, result, "'DoAnotherComplexOperation()' does not yield the expected result.");     

    }     

    [Test, TestsOn("DoOneMoreComplexOperation")]     

    [Row(0, 0, 0, 0)]     

    [Row(0, 567, -567, 567 * 2)]     

    [Row(1, 2, 2, 1)]     

    public void DoOneMoreComplexOperation_ReturnsExpectedResult(int temp, int arg1, int arg2, int expectedResult)     

    {     

        int result = new Calculator().DoOneMoreComplexOperation(temp, arg1, arg2);     

        Assert.AreEqual(expectedResult, result, "'DoOneMoreComplexOperation()' does not yield the expected result.");     

    }     

    [Test, Isolated, TestsOn("DoSomeComplicatedCalculation")]     

    public void DoSomeComplicatedCalculation_VerifiesTheIntendedInteractions()     

    {     

        // Arrange     

        const int resultFromDoSomeComplexOperation = -999;     

        const int resultFromDoAnotherComplexOperation = 1234;     

        const int arg1 = -1;     

        const int arg2 = 42;     

        var calculator = Isolate.Fake.Instance<Calculator>();     

        Isolate.WhenCalled(() => calculator.DoSomeComplicatedCalculation(0, 0))     

               .CallOriginal();     

        Isolate.WhenCalled(() => calculator.DoAnotherComplexOperation(0, 0, 0))     

               .WillReturn(resultFromDoAnotherComplexOperation);     

        Isolate.WhenCalled(() => calculator.DoSomeComplexOperation(0, 0))     

               .WillReturn(resultFromDoSomeComplexOperation);     

        // Act     

        int result = calculator.DoSomeComplicatedCalculation(arg1, arg2);     

        // Assert     

        Isolate.Verify.WasCalledWithExactArguments(() => calculator.DoSomeComplexOperation(arg1, arg2));     

        Isolate.Verify.WasCalledWithExactArguments(() => calculator.DoAnotherComplexOperation(resultFromDoSomeComplexOperation, arg1, arg2));     

        Isolate.Verify.WasCalledWithExactArguments(() => calculator.DoOneMoreComplexOperation(resultFromDoAnotherComplexOperation, arg1, arg2));     

    }     

}

- Needless to say that the above represents an ideal case, which is not always what you can fully achieve in the real (business) world, where there may be all kinds of other factors in operation (timelines, lack of resources etc.)... -

A practical note: Because I consider access to internal members as an everyday standard in my development practice, I have a naming convention in place in my projects (test assemblies are named after the assembly they are targeting, followed by an additional .Test), and I have a corresponding R# live template which generates the required InternalsVisibleTo statement for me.

Don't get me wrong: I'm not saying that the above necessarily is somehow preferable or better than anything else – it totally depends on the concrete project and the testing strategy that you apply to it. I'm only stating that Testing Non-Public Members is a perfectly valid testing strategy in its own right. And in some situations, it might be the only one – namely, if you're consequently doing TDD (never write a single line of code when there's no test for it!) and at the same time you want to keep your class' publicly accessible interface as small and clean as possible.

#3: "Never change production code only to make it testable"

Why not?

As I pointed out in another post, software maintenance makes up by far the biggest portion of a software system's total lifecycle costs, and effective tests help to significantly lower these costs. So if testing can have such a massive positive impact on a companies' budget, why would I then categorially exclude this option only to stick to some theoretical principles?

Of course, like with any other methodology, you have to apply it wisely. The primary goal of production code is to mimick its relating business domain as closely as possible, and it's a very bad idea to shape it after a developer's testing skills in the first place. But usually there is more than one way to skin a cat, and some of them make testing easier, while others will make it harder.

Testability is an important non-functional property of a codebase, so it should not be handled differently than other non-functional requirements. If there's a strong enough reason to change the code accordingly, then just do it.

#4: "TDD is a software design method"

Not really, or at least only to some extend.

It's true that developing your code the TDD way will automatically lead you to well-designed code at the micro level – it's simply not possible to write meaningful tests for spaghetti-, or otherwise poorly shaped, code.

But this effect doesn't apply to the system level. You need to have a clear idea of things like e.g. Class structure, Assembly partitioning, or Code layering before you can start to write the first line of code. And to do this, you need to have good knowledge about software design (Design patterns, S.O.L.I.D. principles, and the like...).

Only then – when your draft is well shaped and generally of high quality upfront – will TDD help you to explore and hammer out the implementation details and will safely lead you down the second half of the road.

So what?

I think, these aspects are to a large extend driven by the view that TDD and software testing is considered as some kind of exotic (or at least somehow special) activity, which should not interfere with the 'real' code. This prejudice often is implicitly accepted and goes unnoticed, because it is buried deeply, at the very heart of Test-driven development. But as soon as you radically change your point of view and consider TDD/testing as the normal and preferable way of writing software (whereas writing software without tests is the exceptional case), some of the 'truths' around 'Textbook-TDD' just don't make much sense anymore...

An introductory presentation about testing with MSTest, Visual Studio, and Team Foundation Server 2010

Thomas Weller — Mon, 21 Feb 2011 19:05:52 GMT

Originally posted on: http://geekswithblogs.net/thomasweller/archive/2011/02/21/an-introductory-presentation-about-testing-with-mstest-visual-studio-and.aspx

While it was very quiet here on my blog during the last months, this was not at all true for the rest of my professional life. The simple story is that I was too busy to find the time for authoring blog posts (and you might see from my previous ones that they’re usually not of the ‘Hey, I’m currently reading X’ or ‘I’m currently thinking about Y’ kind…).

Anyway. Among the things I did during the last months were setting up a TFS environment (2010) and introducing a development team to the MSTest framework (aka. Visual Studio Unit Testing), some additional tools (e.g. Moq, Moles, White), how this is supported in Visual Studio, and how it integrates into the broader context of the then new TFS environment.

After wiping out all the stuff which was directly related to my former customer and reviewing/extending the Speaker notes, I thought I share this presentation (via Slideshare) with the rest of the world. Hopefully it can be useful to someone else out there…

Introduction to testing with MSTest, Visual Studio, and Team Foundation Server 2010

View more presentations from Thomas Weller.

Be sure to also check out the slide notes (either by viewing the presentation directly on Slideshare or - even better - by downloading it). They contain quite some additional information, hints, and (in my opinion) best practices.

dotCover - a new kid on the (development) block

Thomas Weller — Fri, 16 Jul 2010 09:34:38 GMT

Originally posted on: http://geekswithblogs.net/thomasweller/archive/2010/07/16/dotcover---a-new-kid-on-the-development-block.aspx

These days, JetBrains (the manufacturer of ReSharper (R#)) released the beta version of a new code coverage tool – dotCover. Because I’m a big fan of the R# add-in, I was particularly curious about having a first look at the newest JetBrains child. Notably, I wanted to see how it would take advantage of its deep R#/VS integration to make code coverage an integral part of a developer’s working experience. Here are my first impressions about it…

Note: Because I’m using NCover for Code coverage analysis at the moment, I cannot help comparing these two tools, although this might not be totally appropriate: dotCover is designed to deeply integrate with R# and Visual Studio, whereas NCover is a stand-alone application. Also, NCover is a mature and feature-rich application, whereas dotCover is in its early infancy…

Some useful related resources (links to website, documentation material and some videos) can be found in my toolbox on Delicious:

dotCover - http://delicious.com/thomasweller/toolbox+dotcover
NCover - http://delicious.com/thomasweller/toolbox+ncover
or both - http://delicious.com/thomasweller/toolbox+code-coverage

About Code Coverage

Much has been written about Code Coverage and about what it can do and what not – see for example here and here. The bottom line is: The single useful aspect of Code Coverage is that it shows you which parts of your production code are NOT covered by any tests, and thus gives you a basis to decide upon those areas: You simply may have overlooked it, or you may have made the explicit decision to not test it.

And this is exactly what I’m interested in when writing tests - be it after the fact (i.e. covering a pre-existing codebase with tests) or be it when authoring new code in a TDD process: I want to quickly see which parts of the production code are covered with tests, and I want to be able to quickly jump to and inspect code which is not. In short: It’s productivity what I’m looking for in the first place. In-depth information - like it is provided by NCover - is part of a broader picture that becomes important when deeply analyzing an entire codebase or monitoring historical trend data. But for now, let’s exclusively focus on the coding process itself…

Running tests with coverage

DotCover will add a new item to the familiar R# menu, which allows you to run tests with coverage just like you would run ‘normal’ tests from R#:

DotCover also adds a new tab to the R# Unit Test Sessions tool window, showing the results of the current coverage run:

From there, you can directly navigate to the code under test via double click, which will be highlighted in red and green according to the measured test coverage:

Navigating from production code to test code

It is also possible to browse your test code <-> production code connections from the other direction. After a coverage run, dotCover will show you which tests are operating on a selected code line when right-clicking it and choosing Show Covering Tests form the context menu:

This will open up a popup window like the one below, giving you a list of relevant tests:

Summary

The dotCover tool makes code coverage analysis as simple and fast as it was never before. It doesn’t provide all the sophisticated features that NCover has (e.g. branch coverage or trend analysis, to name just two…), but instead it integrates deeply with your coding process and lets you browse and navigate between test code and production code inside VS with only one or two mouse clicks while highlighting the covered/uncovered code areas. Unlike NCover, there’s no need to switch between different applications and to figure out complicated sets of options and/or command lines. Especially when used with a consequent TDD process (like the one I described here in some detail), dotCover is a great help in writing tests and can strongly boost a developer’s productivity.

That’s the pro side of the coin. The contra for now is, that there is not yet any automation support – meaning that it’s not yet possible to use dotCover coverage reports from a Continuous Integration process. This is where NCover is quite ahead at the moment: It allows you to generate nice and detailed coverage reports and data from the command line or via MSBuild/NAnt tasks and thus can seamlessly be integrated with a CI tool like e.g. CruiseControl.NET.

Conclusion

DotCover does a great job on the development side of things, because it integrates perfectly with R# and VS. From a developer’s point of view, code coverage never was easier. This part of the picture is really impressing IMHO. (And as a side note: Although the current version is in a quite early beta state, I found it to be impressingly stable…)

However, there is not yet any automation support (a command-line interface and probably some MSBuild and NAnt tasks), so dotCover cannot be integrated with any Continuous Integration tool at the moment, which (at least for me) means that it’s not yet ready for production regarding the current feature set. But as said before, dotCover is in an early beta, and these features are announced for the final 1.0 version. Like the JetBrains people put it:

dotCover is still in its infancy and we’ve got a lot planned in terms of features and functionality. Quite a few people have asked whether it will support running coverage reports from a console, which is important for continuous integration. dotCover will support running from a console with some basic functionality, and we have plans to include specific features for CI processes.

So let’s just look forward to the things to come…

Mocking the Unmockable: Using Microsoft Moles with Gallio

Thomas Weller — Wed, 28 Apr 2010 11:36:39 GMT

Originally posted on: http://geekswithblogs.net/thomasweller/archive/2010/04/28/mocking-the-unmockable-using-microsoft-moles-with-gallio.aspx

Update 29/04/10:

In contrary to what I initially stated in this post, Moles is not only available as part of the Pex framework, but also stand-alone on Visual Studio Gallery, and this is completely free (no MSDN subscription required). - Thanks to Peli for the correction...

Usual opensource mocking frameworks (like e.g. Moq or Rhino.Mocks) can mock only interfaces and virtual methods. In contrary to that, Microsoft’s Moles framework can ‘mock’ virtually anything, in that it uses runtime instrumentation to inject callbacks in the method MSIL bodies of the moled methods. Therefore, it is possible to detour any .NET method, including non-virtual/static methods in sealed types. This can be extremely helpful when dealing e.g. with code that calls into the .NET framework, some third-party or legacy stuff etc…

Some useful collected resources (links to website, documentation material and some videos) can be found in my toolbox on Delicious under this link:

http://delicious.com/thomasweller/toolbox+moles

A Gallio extension for Moles

Originally, Moles is a part of Microsoft’s Pex framework and thus integrates best with Visual Studio Unit Tests (MSTest). However, the Moles sample download contains some additional assemblies to also support other unit test frameworks. They provide a Moled attribute to ease the usage of mole types with the respective framework (there are extensions for NUnit, xUnit.net and MbUnit v2 included with the samples). As there is no such extension for the Gallio platform, I did the few required lines myself – the resulting Gallio.Moles.dll is included with the sample download.

With this little assembly in place, it is possible to use Moles with Gallio like that:

[Test, Moled]

public void SomeTest()

...

What you can do with it

Moles can be very helpful, if you need to ‘mock’ something other than a virtual or interface-implementing method. This might be the case when dealing with some third-party component, legacy code, or if you want to ‘mock’ the .NET framework itself.

Generally, you need to announce each moled type that you want to use in a test with the MoledType attribute on assembly level. For example:

[assembly: MoledType(typeof(System.IO.File))]

Below are some typical use cases for Moles. For a more detailed overview (incl. naming conventions and an instruction on how to create the required moles assemblies), please refer to the reference material above.

Detouring the .NET framework

Imagine that you want to test a method similar to the one below, which internally calls some framework method:

public void ReadFileContent(string fileName)

    this.FileContent = System.IO.File.ReadAllText(fileName);

Using a mole, you would replace the call to the File.ReadAllText(string) method with a runtime delegate like so:

[Test, Moled]

[Description("This 'mocks' the System.IO.File class with a custom delegate.")]

public void ReadFileContentWithMoles()

    // arrange ('mock' the FileSystem with a delegate)

    System.IO.Moles.MFile.ReadAllTextString =

        (fname => fname == FileName ? FileContent : "WrongFileName");

    // act

    var testTarget = new TestTarget.TestTarget();

    testTarget.ReadFileContent(FileName);

    // assert

    Assert.AreEqual(FileContent, testTarget.FileContent);

Detouring static methods and/or classes

A static method like the below…

public static string StaticMethod(int x, int y)

    return string.Format("{0}{1}", x, y);

… can be ‘mocked’ with the following:

[Test, Moled]

public void StaticMethodWithMoles()

    MStaticClass.StaticMethodInt32Int32 = ((x, y) => "uups");

    var result = StaticClass.StaticMethod(1, 2);

    Assert.AreEqual("uups", result);

Detouring constructors

You can do this delegate thing even with a class’ constructor. The syntax for this is not all too intuitive, because you have to setup the internal state of the mole, but generally it works like a charm. For example, to replace this c’tor…

public class ClassWithCtor

    public int Value { get; private set; }

    public ClassWithCtor(int someValue)

        this.Value = someValue;

… you would do the following:

[Test, Moled]

public void ConstructorTestWithMoles()

    MClassWithCtor.ConstructorInt32 =

           ((@class, @value) => new MClassWithCtor(@class) {ValueGet = () => 99});

    var classWithCtor = new ClassWithCtor(3);

    Assert.AreEqual(99, classWithCtor.Value);

Detouring abstract base classes

You can also use this approach to ‘mock’ abstract base classes of a class that you call in your test. Assumed that you have something like that:

public abstract class AbstractBaseClass

    public virtual string SaySomething()

        return "Hello from base.";

public class ChildClass : AbstractBaseClass

    public override string SaySomething()

        return string.Format(

            "Hello from child. Base says: '{0}'",

            base.SaySomething());

Then you would set up the child’s underlying base class like this:

[Test, Moled]

public void AbstractBaseClassTestWithMoles()

    ChildClass child = new ChildClass();

    new MAbstractBaseClass(child)

                SaySomething = () => "Leave me alone!"

        .InstanceBehavior = MoleBehaviors.Fallthrough;

    var hello = child.SaySomething();

    Assert.AreEqual("Hello from child. Base says: 'Leave me alone!'", hello);

Setting the moles behavior to a value of MoleBehaviors.Fallthrough causes the ‘original’ method to be called if a respective delegate is not provided explicitly – here it causes the ChildClass’ override of the SaySomething() method to be called.

There are some more possible scenarios, where the Moles framework could be of much help (e.g. it’s also possible to detour interface implementations like IEnumerable<T> and such…). One other possibility that comes to my mind (because I’m currently dealing with that), is to replace calls from repository classes to the ADO.NET Entity Framework O/R mapper with delegates to isolate the repository classes from the underlying database, which otherwise would not be possible…

Usage

Since Moles relies on runtime instrumentation, mole types must be run under the Pex profiler. This only works from inside Visual Studio if you write your tests with MSTest (Visual Studio Unit Test). While other unit test frameworks generally can be used with Moles, they require the respective tests to be run via command line, executed through the moles.runner.exe tool. A typical test execution would be similar to this:

moles.runner.exe <mytests.dll> /runner:<myframework.console.exe> /args:/<myargs>

So, the moled test can be run through tools like NCover or a scripting tool like MSBuild (which makes them easy to run in a Continuous Integration environment), but they are somewhat unhandy to run in the usual TDD workflow (which I described in some detail here). To make this a bit more fluent, I wrote a ReSharper live template to generate the respective command line for the test (it is also included in the sample download – moled_cmd.xml). - This is just a quick-and-dirty ‘solution’. Maybe it makes sense to write an extra Gallio adapter plugin (similar to the many others that are already provided) and include it with the Gallio download package, if there’s sufficient demand for it.

As of now, the only way to run tests with the Moles framework from within Visual Studio is by using them with MSTest. From the command line, anything with a managed console runner can be used (provided that the appropriate extension is in place)…

A typical Gallio/Moles command line (as generated by the mentioned R#-template) looks like that:

"%ProgramFiles%\Microsoft Moles\bin\moles.runner.exe" /runner:"%ProgramFiles%\Gallio\bin\Gallio.Echo.exe" "Gallio.Moles.Demo.dll" /args:/r:IsolatedAppDomain /args:/filter:"ExactType:TestFixture and Member:ReadFileContentWithMoles"

-- Note: When using the command line with Echo (Gallio’s console runner), be sure to always include the IsolatedAppDomain option, otherwise the tests won’t use the instrumentation callbacks! --

License issues

As I already said, the free mocking frameworks can mock only interfaces and virtual methods. if you want to mock other things, you need the Typemock Isolator tool for that, which comes with license costs (Although these ‘costs’ are ridiculously low compared to the value that such a tool can bring to a software project, spending money often is a considerable gateway hurdle in real life...). The Moles framework also is not totally free, but comes with the same license conditions as the (closely related) Pex framework: It is free for academic/non-commercial use only, to use it in a ‘real’ software project requires an MSDN Subscription (from VS2010pro on).

The demo solution

The sample solution (VS 2008) can be downloaded from here. It contains the Gallio.Moles.dll which provides the here described Moled attribute, the above mentioned R#-template (moled_cmd.xml) and a test fixture containing the above described use case scenarios. To run it, you need the Gallio framework (download) and Microsoft Moles (download) being installed in the default locations.

Happy testing…

A delicious toolbox

Thomas Weller — Sat, 27 Feb 2010 13:50:58 GMT

Originally posted on: http://geekswithblogs.net/thomasweller/archive/2010/02/27/a-delicious-toolbox.aspx

One of my major points of interest as a software developer is in the various tools that are available to make a developer’s life easier (or at least more interesting…). This is also a very important aspect for me in professional terms, because one part of my job lies in recommending suitable tools to my customers, implementing them and make them part of a developer team’s workflow. Thus, a well organized link collection is an important part of my assets and has a considerable business value for me - I already mentioned that here.

The overwhelming majority of these links point to some sort of freely available stuff - mostly to OSS projects, related extensions, documentation and the like. I greatly benefit from them in business and professional terms, so it’s only fair to share it back to the community. Maybe it will be useful to other people as well...

Therefore, I decided to make my bookmark collection available via Delicious. It is intended to be a central repository for any kind of software development tools, libraries and frameworks that are helpful for C# development; a commented and organized repository which can grow and develop over time, and is easily available from everywhere, both for me and for everyone else.

What’s inside ?

The toolbox features mainly OSS projects that deal with productivity and code quality issues in the area of C# development, together with some useful links surrounding these tools (like for example relating documentation and relevant blog posts), but occasionally also commercial tools, if I feel that this makes sense. I’ll be not too strict with that: Basically, everything that revolves around my development practice (be it commercial or non-commercial) may appear here. My only not-negotiable requirement for a tool to be included in my toolbox is that it must have the capability to be seamlessly integrated with the usual software development workflow (using Visual Studio and a Continuous Integration server like e.g. CCNet).

As for the start, the toolbox covers these tools:

Subversion
http://delicious.com/thomasweller/toolbox+subversion
http://delicious.com/thomasweller/toolbox+SVN

Mercurial
http://delicious.com/thomasweller/toolbox+mercurial
http://delicious.com/thomasweller/toolbox+Hg

Git
http://delicious.com/thomasweller/toolbox+Git

CruiseControl.NET
http://delicious.com/thomasweller/toolbox+cruisecontrol.net
http://delicious.com/thomasweller/toolbox+ccnet

MSBuild
http://delicious.com/thomasweller/toolbox+msbuild

LINQPad
http://delicious.com/thomasweller/toolbox+linqpad

This selection is by no means any kind of judgment, rather it roughly mirrors the things with which I’m dealing at the moment. The list will constantly grow in the future…

How is it organized ?

As you might probably know, bookmarks on Delicious are organized by tags rather than in a hierarchical directory structure. Here is a list of some tags/tag categories that I will regularly use to organize the collection:

toolbox - This is the ‘root tag’ (I know, it doesn’t make much sense to use hierarchical notions like that…). So the ‘base address’ of the bookmark collection is http://delicious.com/thomasweller/toolbox.
<toolname> - The name of the tool that this bookmark is about (full name and eventually common abbreviations). Example: subversion, SVN…
<keywords/categories> - This is pretty free-style and serves to further organize and index the links. Examples: version-control, VCS, coding-guidelines, static-analysis…
<relates-to> - The tool(s) to which this bookmark relates (e.g. as a plug-in, add-in, or piece of documentation).
add-on - This piece of software is an extension – usually a plug-in or add-in, or a collection of them - for the software that appears in the other tags of this bookmark.
documentation - This bookmark links to some sort of documentation relating to the software that appears in the other tags.
<documentation-kind> - Applies to documentation links only. Describes what sort of documentation this link refers to. Examples: e-book, blog-post, wiki…
<license-kind> – Applies only to software. The kind of license of the software. One of opensource, free, commercial. If there’s a dual licensing model (e.g. db4o or MySQL), then the free one is used.

Examples:

A blog post which explains or demonstrates some aspect of CruiseControl.NET may have the following tags:
toolbox cruisecontrol.net CCNet documentation blog-post
AnkhSVN, an open source Visual Studio add-in for Subversion will be tagged like this:
toolbox ankhsvn subversion SVN visualstudio addin opensource

Navigation using tags on Delicious is pretty simple: You just add the desired tags to the base URL using the '+’ sign – i.e.: http://delicious.com/thomasweller/toolbox+<toolname>[+<othertags>].

Example:

If you are interested in all sort of documentation that is somehow related to the Git SCM, then you would use this URL: http://delicious.com/thomasweller/toolbox+Git+documentation

OpenSource, free, or commercial ?

When I thought about the organization of the bookmarks collection, one question was whether to have or not to have tags that describe the underlying business model of a tool. In the end, I decided to include this information, albeit in a very coarse-grained form. Here’s why:

My experience is that from a commercial project’s business perspective, it mostly doesn’t make much sense in the end to distinguish between commercial and non-commercial tools – if you think about costs, you have to think in terms of Total cost of ownership rather than in terms of license costs. But on the other hand, I made the experience that the willingness to try out something new is usually much bigger if the tool comes with no initial license costs.

To me personally, it doesn’t really matter whether something is commercial or not, as long as I see value in it – it basically is a cost-benefit calculation. Sure, I’d always prefer the OpenSource solution, if there’s something to choose, simply because OSS software follows a ‘business model’ that I believe to be highly superior to others, also it is much more flexible and generally has a higher quality standard than a commercial package (at least there always is the potential for that, because OSS projects benefit from the renowned Wisdom of the crowd - only very large companies like e.g. Microsoft can compete with that). Of course, some software products are too heavy for being written and reliably maintained by the community (like e.g. Visual Studio). They need many resources - financial, organizational, and in terms of manpower. And they are definitely worth their price.

Last notes

The blog now has a tag cloud with the delicious tags on the right (‘Delicious Toolbox’ in the ‘News’ section).
Feel free to leave a comment if you think that something should be included into the collection…

Making Selenium 1.0.1 work with Firefox 3.6

Thomas Weller — Sun, 14 Feb 2010 09:00:15 GMT

Originally posted on: http://geekswithblogs.net/thomasweller/archive/2010/02/14/making-selenium-1.0.1-work-with-firefox-3.6.aspx

These days, I’m doing a bit of end-to-end acceptance web testing using the Selenium framework. Selenium has a nice and handy add-on for the Firefox browser – the Selenium IDE. It automatically records your actions and produces the required C# code for you, as you click around in the browser window.

But when I started the Selenium server and tried to run my first test (copied from the Selenium docs), it didn’t work (Sigh. It never works on the first try…) and I got a timeout and an exception. This is what my Gallio test report showed:

Huh? A file could not be deleted (obviously a temporary file that is internally used by the browser)? The Selenium docs were not of much help here.

When I thought it over for a minute, I started to suspect what the real, underlying problem could be: I’m using the new 3.6 version of Firefox, which is about half a year more recent than the current Selenium release. So it might be again an incarnation of our good old friend named ‘version mismatch’… Searching Google for ‘selenium firefox 3.6’ quickly revealed that I was right: the problem simply is that the Selenium server only accepts Firefox versions up to 3.5. This can easily be corrected. Here’s how:

--- Remark: The following solution includes the usage of the free 7-Zip file archiver. --

1. In Windows Explorer, go to the directory where your Selenium server is located (i.e. where the ‘selenium-server.jar’ file lives). After you made a backup of the original file, open it directly with 7-Zip (a *.jar file is actually a compressed archive).

2. We need to patch five instances of a file called ‘install.rdf’ (they actually are small xml files). These files can be found at the following locations in the ‘selenium-server.jar’ archive:

customProfileDirCUSTFF/extensions/

{538F0036-F358-4f84-A764-89FB437166B4}

readystate@openqa.org

customProfileDirCUSTFFCHROME/extensions/

{503A0CD4-EDC8-489b-853B-19E0BAA8F0A4}

{538F0036-F358-4f84-A764-89FB437166B4}

readystate@openqa.org

3. Open each of these files (directly from within 7-Zip) with Notepad or any other text/xml editor. Replace the following text…

<em:maxVersion>3.5.*</em:maxVersion>

… with this (you might have guessed it already):

<em:maxVersion>3.6.*</em:maxVersion>

4. Notepad (or your favorite text/xml editing tool) will ask you to confirm your changes, and so will 7-zip immediately after the file change. Confirm all, close the archive after you’re done, and start the selenium server as usual.

Happy testing…

miniSCRUM – things can be soo easy and simple

Thomas Weller — Tue, 02 Feb 2010 05:21:19 GMT

Originally posted on: http://geekswithblogs.net/thomasweller/archive/2010/02/02/miniscrum-ndash-things-can-be-soo-easy-and-simple.aspx

Yesterday, I occasionally stumbled upon miniSCRUM, a free online Scrum tool. It’s for sure not the first Scrum project management tool that I examined – but the ones that I’ve seen and tried so far were too complicated and/or required too much knowledge about Scrum or the tool itself or both. In the end, these tools always introduced more problems than they solved, they got in my development way and made me less productive, not more.

Not so miniSCRUM. It’s dead simple and therefore totally intuitive in its usage. In fact, it takes longer to read the documentation than just to begin using it. It’s a perfect example for the KISS principle: Only the bare minimum of Scrum features are available, and a five-minute introduction to the basic ideas behind Scrum is enough to understand them.

If you want to give Scrum a try, or play around with the idea of iterative project planning/estimating, or do some Solo Scrum for your own personal stuff, or if you don’t care too much about the theoretical background of Scrum (at least not in the beginning), then miniSCRUM is for you. It’s a perfect starting point to see how it feels and how it can work for you. All you need is an OpenID to sign in.

I immediately and hopelessly fell in love with miniSCRUM. I will use it for my own personal projects and I will also recommend it to anyone who wants to give Scrum a first try…