Why does IIS fail when I reference a .NET 3.5 assembly in ASP.NET?

I added a reference to a .NET 3.5 assembly in one of our ASP.NET web pages. Visual studio warned me that the website project was using .NET 2.0 and needed to be upgraded to use 3.5. So I right clicked on the web project, changed it to use 3.5, and added my reference. All was well with the world…

…That is until I hear the clear “DOH!!!” from my CCTray app, and the dreaded “Red ‘C’” icon, indicating that I just broke the build.  “Doh!!!” indeed!

This perplexed me for a while until I realized that our app does not deploy a web.config file. However, the web.config file contains the setting telling IIS what compiler (2.0, 3.5) to use. Once I realized this, I created a web.config, committed it to svn, and got the familiar “Whoohoo!” sound from CCTray along with the nice “Green ‘C’”. All is once again well with the world!

For more information on this issue, check out:


Posted in ASP.NET, IIS | Tagged , , | Leave a comment

Screencast of my Integration Testing and Fluent Builder presentation at Austin Code Camp 2009

I gave my first public presentation today at the Austin Code Camp. It was titled: “Big Picture Testing – Fluently building complex object graphs for integration tests”. I recorded it as a screencast and attached it below. Overall, I feel it went VERY well. I would be interested to hear what you think. I am opening the floor to constructive criticism. What could I have done better?

FYI, if you want to download the flv file directly, you can get it at: http://chrisedwards.dreamhosters.com/media/CodeCampScreenCast-BigPictureTesting-FluentTesting.flv

Get Flash to see this player.


Posted in Design, Fluency, Patterns, Presentations, Principles, Testing | Tagged , , , , , , | 5 Responses

Utility: WizMouse, scroll wherever your mouse is

A coworker of mine suggested this utility and I really liked it. It allows your mouse to scroll whatever window is beneath it regardless of whether that window has the focus or not.



Posted in Tools, Utilities | Tagged , | Leave a comment

Three Principles for Tests Touching the Database

I have found three principles that really improve the stability and maintainability of our integration tests that hit the database. These principles are intended for automated tests running through some unit testing framework that access the database in any way.

Data Self-Sufficiency

A test should insert any data it needs into the database. The converse is true: A test should not depend upon pre-existing data in the database.

A common problem with test frameworks that depend upon data in the database is that they are fragile. Any change to the underlying data and the test fails. What makes it even more of a problem is that the failure is a “false-negative”. There is nothing wrong with the code, but it fails. A test that inserts its own data will not suffer from this fragility because the data it depends on cannot be changed without modifying the test itself.

Intrinsic Data Assurance

For data that is intrinsic to the system (required for operation), tests should be written to assert its existence.

Some data simply MUST be in the database for the application to function. This data is “intrinsic” to the operation the application. Because the application will fail if this data does not exists, we should write tests asserting its existence. If this required data ever changes or disappears, our tests will immediately notify us and we can correct the issues.

Side-Effect Free

A test should rollback any changes it makes to the database regardless of whether the test passes or fails.

This principle really just tells you what your mom always said, “clean up after yourself”. Don’t leave garbage behind. Your database should not be littered with test data from previous test runs. The easiest way to achieve this is to run the test in a transaction that is rolled back upon completion. I do this using a base class for all database tests called AutoRollbackDatabaseTest. The SetUp() method starts the transaction and the TearDown() rolls it back.

An additional advantage to following this principle is that you are able to run your tests in any environment without the fear of introducing dirty data into that environment. For instance, the tests can be run against DEV, TEST, or PRODUCTION.

In conclusion, the goal behind these principles “The Autonomous Test”: that each test is self-contained and independent of external constraints.  An Autonomous Test is resilient to changes in the system around it, resulting in lower maintenance effort and higher reliability. Following these principles is one way to help drive toward that goal.


Posted in Principles, Testing | Tagged , , | Leave a comment

Presenting at Austin Code Camp 2009

I will be presenting at the Austin Code Camp 2009 next weekend. Its a FREE event next Saturday (May 30th) from 8am-5pm. Lunch is provided. If you are a developer and are able to make it, I highly recommend attending. I attended last year, and I learned a lot and walked away energized and excited. It was great, and I expect this year to be even better.

I will be presenting on creating a fluent interface (DSL) over your domain objects to enable you to easily build complex scenarios for testing. Here is the abstract I submitted:

“Big Picture” Testing: Fluently specifying complex scenarios for integration tests. (1 hour)

Level: 100 Track: Code Camp

Abstract: Have you cringed at writing or maintaining integration tests because setting up the objects or test data needed for the test was just too much work? Have you pulled your hair out over test setup methods that are longer than the latest Stephen King novel? Tired of tests breaking because somebody changed something in the database? Tired of “ignoring” tests because you can’t make them work? Learn testing patterns that will enable you to create a fluent interface to set up complex test scenarios in a way that is concise, clear and easy maintain. Dynamically specify and generate the objects needed for each test scenario using minimal code. Temporarily persist these object graphs to the database for coarser grained “db” tests. Learn principles and practices for developing integration tests against a database using a unit testing framework. Send your “monster” test setup methods back to the closet and simplify your tests.

Here is an example of a fluent interface that can be built using this process:

52 // Arrange.

53 institution =

54 an.Institution

55 .with( a.Product

56 .ofType( ProductTypes.Savings )

57 .with( a.Feature

58 .forSecondaryProcessing()

59 .with( a.Reward.usingMethod( rewardProcedureName ) )

60 )

61 )

62 .with( a.Cycle.withSecondaryProcessingDateOf( DateTime.Today ) )

63 .build();

I hope to see you there!


Posted in Presentations, Testing | Tagged , , | Leave a comment