Chris McKenzie's Blog : Test Driven Development (TDD)

Here's a question

taganov — Mon, 17 Apr 2006 21:09:00 GMT

I've been practicting Test Driven Development pretty religiously for about a year now. That and the reading I've done on design patterns and software architecture have dramatically improved my software design and quality. I've got an automated build server set up as well.

That said, I need to print a Reporting Services report directly to the printer. I have code that works, but I haven't been able to figure out how to write a unit test for this that can be executed by the build server. I don't want the build server to send the report to an in-house printer everytime it runs. I'd much rather print it to a file, but a file printer asks for user input (the file name).

Any ideas?

Humor for Agile Developers

taganov — Mon, 06 Feb 2006 19:19:00 GMT

Especially funny to me is wordUnit!

http://www.waterfall2006.com/

On explaining the importance of a Data Access Layer

taganov — Tue, 12 Apr 2005 14:54:00 GMT

Nice blog from David Mauri on explaining the importance of a Data Access Layer.

More on Implementing an Interface in the UI, or the 7-layer system.

taganov — Wed, 06 Apr 2005 02:30:00 GMT

Matt Berther is doing something similar to what I was talking about in my previous post.

Where we differ is where to do the validation of the business rules. He's wrapping his IMyView in a class that knows how to perform the Business Rule validation. I didn't discuss my validation method in my last post, so I'll discuss it here:

Let's say I have a class that knows how to save an IPerson to a DataStore. The Save Method signature looks like:

Public Function Save(p as IPerson) as Boolean

If my Web page or UserControl implements IPerson, I can simply pass the entire page or UserControl to the Save method of my Data Access object. But where does the validation get done? It gets done during the save attempt. The UI layer does not have direct access to the Data Access layer. It has indirect access via a set of FACTORY objects. When the UI attempts to save, it does so through a FACTORY class that first performs validation of the Business Rules, and if everything is okay, continues with the save. If the validation fails, then a list of errors is returned to the UI via an event handler.

This separation of Business Rule Objects (policy) from Business Data Objects (data) and Data Access objects (persistence) allows for easily turning various business rules on and off. As new rules are added, old ones are removed, or existing ones change their optional status, only one layer has to be modified: the validation layer. Additionally, this layer can itself be stored in the Data Store and configured dynamically. The UI can and should perform its own validation, but if it doesn't, no harm is done to the underlying system.

Consider the following example. Assume an interface IPerson defined as follows:

Public Interface IPerson

Property IsACompany() As Boolean

Property CompanyName() As String

Property FirstName() As String

Property MiddleName() As String

Property LastName() As String

Property Address() As IAddress

Property Contact() As IContactInformation

End Interface

Public Interface IAddress

Property Address1() As String

Property Address2() As String

Property City() As String

Property State() As String

Property PostalCode() As String

End Interface

Public Interface IContactInformation

Property PhoneNumbers() As System.Collections.Specialized.NameValueCollection

Property EmailAddresses() As System.Collections.Specialized.NameValueCollection

End Interface

Consider the following Business Rules: In IPerson, the LastName is required if it is, if fact, a person. The CompanyName is required if the IPerson is a company (anybody have a better name for IPerson that supports it being either a human or a company?)

My FACTORY Object might look like this:

Public Class FactoryObject

Public ReadOnly Property SecurityContext() As SystemUser

' snipped for brevity

Public Function Save(ByVal p As IPerson) As Boolean

Dim V As New IPersonValidator(p)

Dim pm As New PersonManager(Me.SecurityContext)

Return pm.Save(p, V)

End Function

End Class

The FACTORY Object simply instantiates the validator as a required parameter to the DataAccess Object's Save() method, hiding this complexity from the client code. The Validator Object might look like this:

Public Class IPersonValidator

Public ReadOnly Property Person() As IPerson

' snipped for brevity

Public ReadOnly Property IsValid() As Boolean

Get

Return Me.ValidateNames

End Get

End Property

Public Function ListErrors() As String()

' snipped for brevity

Protected Function ValidateNames() As Boolean

Dim Result As Boolean = True

If Me.Person.IsACompany Then

Result = Me.Person.CompanyName.Trim <> String.Empty

Else

Result = Me.Person.LastName.Trim <> String.Empty

End If

Return Result

End Function

Public Sub New(ByVal p As IPerson)

' snipped for brevity

End Class

And finally, the Save() method on the Data Access object might look like:

Public Function Save(ByVal p As IPerson, ByVal V As IPersonValidator) As Boolean

Dim Result As Boolean = False

If Not V.IsValid() Then

'Raise a ValidationError event

'snipped for brevity

Else

Result = Me.SaveToDataStore(p) ' execute SQL to store IPerson in Database

End If

Return Result

End Function

I'd be interested in any feedback from the community on this approach. This is something that I've started doing recently and so far it's working out rather nicely. There may be pitfalls that I can't see yet, so if you see any major problems with this, ping me :-). You can ping me if you like it too :-P.

Culmination

taganov — Fri, 01 Apr 2005 02:26:00 GMT

I've been reading about and applying Test Driven Development and Design Patterns over the last few months. Today I saw the culmination of that effort in the design of new module of ASP .NET software that was added to an existing project on Monday.

Early on I had created a generic object for leafing through pages of records in the database. I called the object the RecordCursor, and implemented basic cursor and search functionality (MoveFirst, MoveNext, etc.). Separately, I had designed a generic object for managing records in the database--I called this a RecordManager. It has 3 basic functions (Save, SaveNew, and Delete), and sometimes has others (ListAll).

Of course, there are also the Business Objects themselves.

For any Business Object in the system, there are basically 3 parts--the business object itself, the Manager, and the Browser. This gives me a good separation of the Business Layer from the Data Access Layer.

I wanted to make the UI solely dependent on Interfaces and Abstract classes. When building my DataAccess components, I made sure that they only returned Interfaces from any API function. I further made sure that none of the concrete objects were visible to the UI.

This is where it starts to get cool. The RecordManager classes receive only interfaces to their Save, SaveNew, and Delete functions. The idea I had for the UI was to develop a set of UserControls that implemented the interface of the object they were intended to edit. Thus, if I have an interface IPerson, then I'll have a PersonEditorControl UserControl that implements IPerson. Instead of creating property declarations with internal variables, I'm redirecting the properties to the server controls embedded on the UserControl.

For Example:

Public Property FirstName as String Implements IPerson.FirstName

Get

return Me.txtFirstName.Text

End Get

Set (value as String)

Me.txtFirstName.Text = value

End Set

End Property

'etc...

Thus, the editor becomes an instance of the object it is intended to edit. When I'm done editing, I simply pass the control in its entirety to RecordManager.Save(p as IPerson).

I've been writing code for about 5 years now, and haven't seen anybody doing this in any existing code, nor in any books. It's worked out pretty well for the project I'm working on, so I thought I'd share.

For an Introduction to TDD...

taganov — Wed, 02 Mar 2005 03:38:00 GMT

Click here. It's a column by Robert C. Martin that illustrates how TDD improves the quality of code.

This line relates directly to my last post, "Tests are users, too. The needs of the tests are often the same as the needs of the real users."

An Unexpected Benefit of TDD

taganov — Tue, 01 Mar 2005 21:58:00 GMT

I've recently begun using Test Driven Development as my method for developing and maintaining applications. A worry I had early on was that I have inherited several poorly designed ASP .NET applications (read "poorly designed" as "not designed") and that it would be difficult to use TDD in that environment.

I was mistaken.

Today I had an issue with a browse page. The code to browse the database was slammed behind the page in a 250-300 line sub routine. Additionally, the same code was being used by 5 different buttons on the page--btnFirst, btnPrevious, btnNext, btnLast, and btnSearch. Given that the page is supposed to allow the user to browse the records a "page" (a set of x number of records) at a time, I thought the ITERATOR pattern most appropriate. I wrote a unit-test for the MoveFirst(pageSize) functionality of the RecordBrowser class, which didn't yet exist.

After implementing the MoveFirst() method, I then went on and wrote tests for--and coded--the MoveNext(), MovePrevious(), MoveLast(), and MoveToSpecificRecord() methods. After writing the tests and verifying that they worked as expected, it was pretty simple to plug the new class behind the page and start using it instead of the existing code. I watched 250+ lines of code in the Code-Behind dwindle to less than 25 lines.

Because I needed to write a test to capture the failure (which ultimately was a failure in a stored procedure call), I had to create an object that I could test in isolation from the UI and surrounding logic. This took a ltitle bit longer up front, but because I had separated out the actual db browsing logic from the UI, I could just work on getting that part to work correctly without having to worry about whether other stuff in the page was messing up the needs of the browing class. I also ended up with a set of new interfaces and abstract classes that I'll be able to re-use when I have to fix errors with other variants of the browser class, which means that the same fix will go much faster next time around.

When it came time to integrate the new class into the existing page, it took hardly any time at all. I had a couple of initial errors, but since I had already tested the browsing object, I knew that these errors were related to things on the page--not the browsing class. Once I got those straightened out, it was a snap to run the program and watch the page browse the db flawlessly.

So now I have a poorly designed web application with one lone piece of well-designed code. It took less than a morning to add the db browser class, and now I'll know that it's still functional every time I work on this program. The reason that I was able to seamlessly insert a piece of well-designed code into the system is because of the nature of TDD--the whole point is to test functionality in isolation. This means that design changes (and additions) are incremental, and have little impact on the larger system (or non-system in this case). BUT--and this is the key point--over time, as bits of quality design are added here and there, the overall quality of the system incrementally improves. As more and more features and issues are added or fixed, the overall system will begin to take on a definite structured design. TDD causes the design to spread and overtake the system.

I am so looking forward to new enhancements on these old projects I inherited.