I’ve just released an update to the UnitTestEx component which as the following additions:

• Re-factored API signatures to make them much simpler
• ExecuteUnitTestScript to support in/out params
• Renamed ExecuteUnitTestValidationScriptReader to ExecuteUnitTestScriptReader which also now supports in params
• Added unit test for all database related features ie ExecuteUnitTestScript
• Added database scripts to allow testing of the new unit tests.
• Compare now supports the ability to treat empty collections as the same as null collections. This feature can be useful if de-serialize your expected results from an XML file and your actual forces some collections to be null but the default behaviour of the code is to have initialized collections.

For anyone who has been using an older version, this version represents a number of breaking changes. The changes however are not significant and the APIs are now quite stable.

If you haven’t checked out the component yet, take a look at the original post and the code on CodePlex.

On my current project I find that I’m working with Visual Studio on a VM that is in an isolated domain, which is making life interesting! One of those ‘interesting’ things was that Debugging in Visual Studio was horrendously slow! It would take several minutes to get to the first break point (first line of a unit test), then still be slow when accessing other parts of the code.

The slow part of the process was the loading of the symbol files for each of the referenced dlls, including those of the .NET framework. As it turns out Visual Studio actually loads the symbol files for the .NET Framework from the internet! So the delay is primarily due to timeouts which lead to an unbearable (read unusable) debugging environment. The good news is that there is a solution which is quite simple and easy to implement.

Solution

In order to dramatically improve your debugging you need to have Visual Studio use a cached version of the symbol files, as well as ensure its not trying to locate symbol files on slow network shares.

Here are the steps you need to fix the issue:

1. Create a directory to store you locally cached symbols. Ie C:\Temp\SymbolCache
2. Change the debug settings for loading symbols, via Tools|Options|Debugging|Symbols.

   

3. (Option 1) Start debugging the code you want (on a machine that can access the internet; even if its slow) and have it sit on a break point. Then go back to the Symbols settings, where you’ll notice the button Load symbols from Microsoft symbol servers is now active (because that was obvious!). Click the button and you’ll see a popup windows indicating the download of the symbol files. After this is complete you can close out of this window and stop debugging. If you now check your Symbol Cache directory you’ll see you have a load of downloaded symbols (may vary depending on what you’ve referenced).

   

4. (Option 2) If you have already done option 1 and you need to apply this to another machine, such as a team members machine, you can simply copy the files from one machine to the other.
5. Depending on your environment you may also have one of two environment variables that need updating. Set either of these environment variables to the same location as the cache created in setup 2. The environment variables to change are _NT_SYMBOL_PATH or _NT_ALT_SYMBOL_PATH. The default setting for these are pointing to the Microsoft Symbols server. You can access the variables either via DOS (set command) or via the Advanced System Properties dialog in Windows.

One you’ve completed the changes you should see a dramatic improvement in your performance. Remember to check in Step 2 that you don’t have any non-existent paths or UNC paths defined as this will also slow things down.

In an effort to start getting more of the code I’ve been working on out in the public domain, I’ve finally released all the code for the dnp.Framework on CodePlex. While its not all complete, most of the code is quite stable and can be used now!

Some of the major components that are included in the framework include:

• Database Explorer API: An object oriented database schema API which is ideal for anyone wanting to do code generation. Its based on the provider pattern, so while it currently only supports SQL Server 2005+ its fairly easy to create a new provider for any system. This is stable enough for production use and has an extensive set of unit tests.
• Data Provider: This is a database agnostic API which is fairly similar to the one in the enterprise library except it doesn’t support datasets and the like. Its also has little overhead. This was designed before the Enterprise Library had a decent model, and it has also been used on mobile devices with the compact framework.
• DomainModeller: An abstract domain model view of a database schema (extends Database Explorer API). This API is most useful to creating scripts for code generation, where you can concentrate on domain concepts such as base classes, derived classes, namespaces and relationships etc, rather than database concepts. Using this API for code generation can significantly reduce the amount of code typically required.
• ServiceModel: This project is still under development, but aims to provide the first ‘Model’ that extends the Domain Modeller to define a Service based Application framework. The ServiceModel acts as the abstract API for the final code generation scripts which are currently written using CodeSmith. The scripts currently have good support for the data access layer (repository), service layer (business logic) and entities (using design discussed here). More...
  

Its been some time since my last post, so I thought I’d start back with news of a small Unit Testing library I’ve been using with my current client. I developed the library to solve a number of issues I was facing while doing my unit tests. The focus of the library is to provide support for:

• Test Spy Pattern: a type of of fake that monitors calls and data passed rather than trying to mock the implementation. A discussion of the pattern can be found in the xUnit Patterns book.
• Comparing entities: the amount of code generally required to test that an entities properties match those of the expected version can be large and tedious to write.
• Data access testing: while using Fakes and the like is great, you still need to test the code that actually talks to the database. This usually ends up taking a reasonable amount of code to setup and execute, making the test harder to read.

This library provides solutions to the above problems which in my experience has produced cleaner tests that are easier to read and understand. The library comes with a fairly detailed User Guide so I wont go into the details of how everything works here, however I will provide a quick overview of how the library attempts to solve these issues.More...

I recently had the task of creating a report where they wanted one of the columns to list out all the users associated with a given report line item in a single comma separated string. My initial thoughts were, that this would involve some type of cursor or at least a loop of some description, which I'd then have to attach to the main result set. However, it seems there's a very nice little trick you can use that will solve this issue without the use of cursors or loops!

With the use of the COALESCE keyword you can create a list in a single line of SQL (except for declarations). I'll use the AdventureWorks database to demonstrate the technique. Assume  you need to get a list of Countries and the regions they contain, in a report similar to the one below: More...