A brainstorm of some ideas. (Feel free to add your own in the comment section).
Certain methodologies, like Agile and TestDriven.Net are designed to fulfill many of these things. For example, by having sufficient unit test coverage, you minimize your regression bugs and get to focus more on new things.
Almost everyone would rather create something new than fix something broken (especially someone else's broken code). However, it's inevitable that some maintenance will always be required. Here are some ideas to make maintenance easier:
The MassDataHandler is a framework to assist with Database Unit Testing. The framework makes it very easy to insert test data into a database, which in turn makes it very easy to write database unit tests. The user merely needs to specify their relevant data in a simple XML fragment, and then the framework uses knowledge of the database schema to do all the grunt work and convert that XML data into SQL, from which it populates the database.
It is an open-source .Net app available here.
We recently improved the install process for the app by having a GUI form collect environmental info for SQL 2005, MSTest, and MSBuild. The install script uses the concept of Having an MSBuild script collect userinput.
If you're looking to test your data layer, check out this free tool. It's now easier to install.
MSBuild is great for automated batch processes. It's easy to set properties in the script itself using the
Why would you do this, given that the whole point of a build process is to be automated? ... Because MSBuild is an automation language, it can be used not just for builds but to
ultimately automate any task. For some tasks that you kick off manually (like installations, deployments, instrumentation, etc...) you may want to collect the user input up front.
Doing this requires three steps.
The first step is easy, lets look at the second one. There are several different ways we can return error information from a WinForm.
With this technique, everything becomes easy: Our MSBuild script can be simple:
Targets="Build"
Properties="Configuration=Debug" />
The WinForm is easy:
static class Program { ////// The main entry point for the application. /// [STAThread] static int Main() { Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); Application.Run(new Form1()); return _intReturnCode; } private static int _intReturnCode = 0; public static int ReturnCode { get { return _intReturnCode; } set { _intReturnCode = value; } } }
We can then set the static variable "ReturnCode" anywhere in the WinForm by setting Program.ReturnCode.
(Note that we can also have the WinForm use Console.Writeline(), which will be logged in the MSBuild script).
Having the MSBuild script take user input is an easy trick to perform, and may be helpful for certain tasks.
About a year ago, I posted on Things that fundamentally change how you program, listing several things:
A year later, there are new things I would add to this list:
All of these things are easy to get started, but they will fundamentally improve how you program. If you want to be a better developer, you'll get a high return from investing in these things.
Unit testing the database is hard - and there are mixed reactions to it. My take is that there could be legitimate logic in the database (transactions, SQL aggregations, reusable functions, complex SP like paging, etc...). The problem with unit-testing the database is creating a test database and filling it with data. At Paylocity, we created a tool called the MassDataHandler to help us unit-test our data layer. We recently open-sourced this tool, and you can download the beta here.
The MassDataHandler is a framework to assist with Database Unit Testing. The framework makes it very easy to insert test data into a database, which in turn makes it very easy to write database unit tests. The user merely needs to specify their relevant data in a simple XML fragment, and then the framework uses knowledge of the database schema to do all the grunt work and convert that XML data into SQL, from which it populates the database.
The XML fragments that contain the test data are robust and refactorable. You can include expressions like variables substitution and identity lookup, default row templates, and include statements to import sub-templates. Because the framework already knows the database schema, you only need to specify the relevant data, and the framework can auto-populate the rest of the row’s required columns with dummy data.
For example, the following Xml script would insert data into three tables - providing you variables, default row templates, and automatically handling the identity lookups and non-null fields:
<Root>
<Variables>
<Variable name="lastName" value="Simpson" />
Variables>
<Table name="Customer">
<Row CustomerName="Homer $(lastName)" />
<Row CustomerName="Marge $(lastName)" />
Table>
<Table name="Product">
<Row ProductName="KrustBurger" Description="best burger ever" />
Table>
<Table name="Order">
<Default LastUpdate="12/23/1997" />
<Row CustomerId="Customer.@1" ProductId="Product.@1" />
<Row CustomerId="Customer.@2" ProductId="Product.@1" />
Table>
Root>
Download the MDH Framework Beta here.
By making it so easy to insert and maintain test data, the MDH framework helps you write database unit tests.
