TDD development follows the Extreme Programming (XP) principle of coding the unit test first. Even though your project may need 200 reports, each with different results, start with a simple test. I start with a scenario of the report. The next section contains the User Story that constitutes our definition.

For instance, one should start with a test that will fail. For a BI project, first test loading a report file into an object successfully. My normal architecture for Crystal projects involves invoking the reports from a physical file location, rather than compiling the reports into a .NET dll. So my first test would look like this:

Listing 1: nUnit Simple Test Code

[Test]
public void TestLoadReport()
{
      CrystalObjects.ReportObjects oCrObjs = new CrystalObjects.ReportObjects();
      oCrObjs.LoadReport(@"C:\Dev\UnitTestBICrystal\SalesReportToTest.rpt");
      Assert.AreEqual(oCrObjs.currDoc.SummaryInfo.ReportTitle,"Customer Orders by Customer");
}

Now this may be a little contrary to normal TDD teaching. Mainstream TDD practices include starting with a test that fails. This assumes you are creating a new object for that test. In this case however, a third party has provided the Crystal Object. I believe that we can forgo the failing test in this case. 

Note that nUnit 2.2 throws an error when utilizing the Crystal Document object directly.  To overcome this problem, I started refactoring a bit earlier, by creating a class based on the Crystal object. That is the CrystalObjects.ReportObjects class in the above nUnit Simple Test Code.

To continue to the next effective test, you must have an idea of what you are testing. In this case, we need to test for a large BI project. Make sure to include explicit Unit Test results in any specification you create. Since BI projects normally have very defined results that the users want, the tests are almost written before you need to code!