April 2004 - Posts
I've been thinking about getting back (was I ever there) into writing more formal articles. Below is an outline of an article which I've been thinking of writing. Does it sound interesting to anyone? What might make it more interesting, useful? How hard is it to get published in a real mag, or even MSDN?
Summary: Unit testing is quickly gaining traction within the .NET community. By unit testing business objects developers are finding they are able to reduce the number of bugs they write, and increase the maintainability of their applications. The benefits of unit testing are well documented; however, unit testing your objects doesn’t come free of charge. Writing unit tests for each method of your business object is time consuming task and often involves a lot of repetitive coding. This article discusses a method that can help reduce the leg work required to create a full suite of unit tests for your class libraries.
Very Rough Outline: Automate Unit Testing With a Base Test Class
- Testing common data operations on objects is tedious
- Although many people believe the database should not be included in unit tests I’ve found it to be very valuable
- Validate the stored procedures function as expected.
- Provides an overall integration test for the application and database.
- Forces you to think about deployment, integration, and setup of the database from the start.
- Forces you into a one click build, from scratch, including the database.
- A base test class can help automate much of the work for testing basic CRUD operations
- Load
- Save
- Delete
- Update
- Find
- Show examples of how basic test are run
- Handle object dependencies, limiting available values, unique fields
- What about validation? Attribute based validation checks (maybe)
- Why is this helpful
- It allows for you to quickly setup a suite of tests for common data related functions for your objects
- Provides all advantages as discussed above (validate procs, integration, design for deploy/integration, one click build, etc.)
- Handles the setup of dependent objects (saves)
- Can be used to ensure validation is working on objects
- Lets you concentrate on the areas of the app that really need the testing, biz logic, etc.
- Overview the framework, explain all aspects of code, provide download with examples.
Roy posted on Notepad2, which seems like a nice replacement for Notepad. The batch file below can be used to replace notepad with Notepad2. Use at your own risk! 
@echo Replacing NOTEPAD.EXE with notepad2.EXE ...
REM
REM 1. Prevent the protected file system from doing its thing.
attrib -r -h -s %systemroot%\system32\dllcache
ren %systemroot%\system32\dllcache\notepad.exe notepad.bak.exe
attrib +r +h +s %systemroot%\system32\dllcache
REM
REM 2. Make backup copies of Notepad in the Windows and System32 folders.
copy %systemroot%\system32\notepad.exe %systemroot%\system32\notepad.bak.exe
copy %systemroot%\notepad.exe %systemroot%\notepad.bak.exe
REM
REM 3. Copy notepad2 to Notepad in the Windows and System32 folders.
copy notepad2.exe %systemroot%\notepad.exe
copy notepad2.exe %systemroot%\system32\notepad.exe
REM
@echo Succeeded.
@echo
@echo NOTE: When the Windows file protection message pops up,
@echo click Cancel, then click Yes to confirm your intentions.
And then to uninstall...
REM Script to uninstall TXPLINK on Windows 2000
REM
@echo Replacing TXPLINK.EXE with NOTEPAD.EXE ...
REM
REM 1. Reinstate Notepad from its backup copies, in the Windows and System32 folders.
copy %systemroot%\notepad.bak.exe %systemroot%\notepad.exe
copy %systemroot%\system32\notepad.bak.exe %systemroot%\system32\notepad.exe
del %systemroot%\notepad.bak.exe
del %systemroot%\system32\notepad.bak.exe
REM
REM 2. Allow the protected file system to do its thing.
attrib -r -h -s %systemroot%\system32\dllcache
ren %systemroot%\system32\dllcache\notepad.bak.exe notepad.exe
attrib +r +h +s %systemroot%\system32\dllcache
REM
@echo Succeeded
Jimmy Nilsson has put together a nice transcript for a talk he's giving at VSLive on Test Driven Development. He offers a nice overview of TDD and its benefits.
Check it out! (pdf) (web)
Jimmy Nilsson has put together a nice transcript for a talk he's giving at VSLive on Test Driven Development. He offers a nice overview of TDD and its benefits.
Check it out! (pdf) (web)
“Nevertheless, even when an assembly contains only a single DLL, the assembly still offers the component developer significant versioning, sharing and security advantages.“ - Programming .NET Components
Grab the nearest book.
Open the book to page 23.
Find the fifth sentence.
Post the text of the sentence in your journal along with these instructions
I use stored procedures for a lot of the data access I do within the applications I develop. Overall I like using stored procedures for data access, however, at times it makes “things” more difficult.
One of the “things“ that it makes more difficult is using optional parameters. In dynamic SQL we can handle optional parameters easily, simple don't append parameters that aren't needed. With stored procedures it isn't quite as straight-forward. My Optional Parameters in SQL Server Search queries post provides a solution.
Another task that is more difficult when using stored procedures is sorting. In many instances we want to be able to pass in the field that the records should be sorted on. Often times this is accomplished by using nested IF/ELSE statements. Although nested IFs do address the problem it also introduces a lot of duplication which we all know is bad. Fortunately there is a better way. Rather then introducing nested IF/ELSE statements to control the ORDER BY of your query use a CASE statement in the ORDER BY of your query.
CREATE PROCEDURE ap_OrderSearch
(
@SortBy varchar(50)
)
AS
select * from orders
ORDER BY
CASE
WHEN @SortBy = 'customerid' THEN CustomerID
WHEN @SortBy = 'shipname' THEN ShipName
WHEN @SortBy = 'shipaddress' THEN ShipAddress
END,
CASE
WHEN @SortBy = 'orderdate' THEN OrderDate
WHEN @SortBy = 'shippeddate' THEN ShippedDate
END,
CASE
WHEN @SortBy = 'orderid' THEN OrderID
WHEN @SortBy = 'employeeid' THEN EmployeeID
END
The above query returns records from the Orders table in the Northwind database. It accepts one parameter which is used to specify the field to sort the results by. The fields are grouped into 3 separate CASE statements by their data type to avoid conversion errors during the execution of the query.
I think Paul Vick has solidified his .NET rock star status with this quote:
“One other thing that annoys me about the software development industry is the common emphasis on methodology over individual skills. Methodologies — such as test driven development, extreme programming, object oriented programming, etc. — all bring something good to the table, but we often lose sight of the fact that they're all means to an end, not ends in and of themselves. A lot of people seem to end up wasting a lot of time worrying about the finer points of some methodology or another, rather than thinking about whether or not it's going to help them personally write better software. “
.NET Rock Star - Paul Vick
+1
James Newkirk (the author of TDD in .NET) has a new article up on MSDN. Check it out...
You would think that since I just finished reading Test Driven Development in Microsoft .NET and am in the middle of Extreme Programming Adventures in C# I would be able to remember to write my failing tests before writing a line of code. Think again. This morning I was working on some code, cranking along. As I began implementing a set of logic I wondered to myself....do I have this right? Loop over this collection, check the property against the expected value, and....DOH! Where are my friggin tests? How did I manage to get this far into writing this code without writing a single test?
Test driven development is hard. All those years writing software without TDD have made it extremely difficult for me to remember the TDD mantra, red...green...refactor! My first instinct is always to dive right into the code without writing a test. Of course as I mentioned yesterday I am always able to remember to think about the big elegant design that I might not ever need. But can I remember to test first, of course not. Time to go catch up on some testing...
You would think that since I just finished reading Test Driven Development in Microsoft .NET and am in the middle of Extreme Programming Adventures in C# I would be able to remember to write my failing tests before writing a line of code. Think again. This morning I was working on some code, cranking along. As I began implementing a set of logic I wondered to myself....do I have this right? Loop over this collection, check the property against the expected value, and....DOH! Where are my friggin tests? How did I manage to get this far into writing this code without writing a single test?
Test driven development is hard. All those years writing software without TDD have made it extremely difficult for me to remember the TDD mantra, red...green...refactor! My first instinct is always to dive right into the code without writing a test. Of course as I mentioned yesterday I am always able to remember to think about the big elegant design that I might not ever need. But can I remember to test first, of course not. Time to go catch up on some testing...
One of the suggestions that the authors of Test Driven Development in .NET, as well as Ron Jefferies in Extreme Programming Adventures in C#, make is to start simple. Rather then writing a full test that tests all the advanced business logic in your objects start with something simple. Write a test that confirms your most basic assumptions. Although at first it seems like a waste of time these simple tests get the ball rolling. TDD is about getting into a groove, red...green...refactor...red...green...refactor. One of the barriers that I often run into is all the thoughts that are running around in my head. Should I choose architecture A, or architecture B? Which one fits the current needs, which one fits the direction I think the application will end up going? What can I optimize, how can I reduce database hits, how can I make this look cleaner, how, how, how...but...what if....?
All these thoughts stop me from doing the most important thing, writing code. I often get caught up in trying to figure everything out before I write a line of code. I think some of this can be attributed to the way many of my peers did things during the time when I was learning the ropes. They've scarred me...them bastards! Rather then trying to figure out everything before you start coding I highly recommend starting with something simple. As the application evolves so to will your code. If the application really needs “that elegant design” you'll know it. Do yourself a favor and start simple.
One of the suggestions that the authors of Test Driven Development in .NET, as well as Ron Jefferies in Extreme Programming Adventures in C#, make is to start simple. Rather then writing a full test that tests all the advanced business logic in your objects start with something simple. Write a test that confirms your most basic assumptions. Although at first it seems like a waste of time these simple tests get the ball rolling. TDD is about getting into a groove, red...green...refactor...red...green...refactor. One of the barriers that I often run into is all the thoughts that are running around in my head. Should I choose architecture A, or architecture B? Which one fits the current needs, which one fits the direction I think the application will end up going? What can I optimize, how can I reduce database hits, how can I make this look cleaner, how, how, how...but...what if....?
All these thoughts stop me from doing the most important thing, writing code. I often get caught up in trying to figure everything out before I write a line of code. I think some of this can be attributed to the way many of my peers did things during the time when I was learning the ropes. They've scarred me...them bastards! Rather then trying to figure out everything before you start coding I highly recommend starting with something simple. As the application evolves so to will your code. If the application really needs “that elegant design” you'll know it. Do yourself a favor and start simple.
Over the Easter holiday I read Test Driven Development with Microsoft .NET. Overall I really enjoyed the book. It provides a solid overview of how to handle some advanced TDD tasks that many other books gloss over.
The book begins with an introduction to test driven development. The authors clearly have a lot of experience (they wrote NUNit) and do a solid job of explaining why TDD can be an extremely valuable design tool. After introducing TDD the authors provide a quick overview of Refactoring by stepping through a sample application. Throughout the book the authors present semi-real life examples to make their point. The authors don't present and implement things in an idealistic way as some other books do, instead they refactor and test as they would a real application.
The chapter that I was looking forward to reading the most was TDD with ADO.NET. Many other TDD books gloss over how to use TDD when a database is involved. Additionally many TDD proponents believe that TDD should not involve the database. The authors present a Media Library example to demonstrate how to use TDD with ADO.NET. The architecture of the sample application is based on datasets. To test the ADO.NET code the examples compare the data retrieved from the database in a dataset with the in memory dataset containing the expected values. Although the examples do offer some very good insights into ways in which developers can use TDD with ADO.NET I was hoping for more. I would have loved to see some more examples including some other architectures based on custom business objects and a domain model. Even so, I got a lot out of the chapter. If nothing else it was good to see that the way I was implementing my tests wasn't totally off base.
The books goes onto cover topics such as TDD with web services, Implementing Customer Tests (with FIT), Transactions, and more. Overall the books offers a lot of valuable information to those getting started with TDD.
As I was reading the book I took notes on my HP 4350. The notes can be found below:
Intro/Overview of TDD
- Never write a line of code without a failing test.
- Eliminate Duplication
- Write a test list 15-20 Minutes per 4hr task
- Test list verifies requirements and Describes completion criteria
- Red/green/refactor
- Focus on what the class does not how it's implemented
Refactoring
- Refactoring improves structure of existing code
- Refactoring makes longterm software ownership less painful
- Need up to date tests before refactoring
- Tests provide safety nets for refactoring
TDD with ado.net
- Typed dataset for populating test database
- Leave relationships off typed dataset to increase testability off individual entities, other tests will verify relationships
- Ideally only one test should fail because of a problem. However this is not always possible when testing db apps, it should remain a goal.
- Dataset based examples not as valuable as custom object examples.
- Tests for entities, relationships and utilities.
- Naming of test classes with Fixture, test method names not testdox'able.
- Organize tests by use, in separate assembly.
- Very useful to have suite of tests that can test/validate db schema and let us know when a change causes problems
TDD with web services
- Write tests to minimize the dependencies
- Want failing test to pinpoint the problem in code
- Isolation reduces debugging
- error checking in stub.code should only be done if the cost outweighs the benefit
- Write dto using schema and xsd.exe
- Map dataset to dto via 'assembler'
- Test in isolation and then introduce database
- Database fixture inherits from implementation fixture
Customer tests
- Allow client to define requirements in an easy to use format/language
- Automated to facilitate feedback
- Fit
- If fit tests require code changes to adapter class what is the real benefit over NUNit?
- Write customer tests first
Transactions
- Use transaction to rollback db to pre test state
- Transaction manager on thread, classes that hit db check if they should join existing transaction or create their own. Done via command pattern.
- Adapters to convert xsd.exe classes into bindable objects
- Separate web code as much as possible to increase testability of the code.
Over the Easter holiday I read Test Driven Development with Microsoft .NET. Overall I really enjoyed the book. It provides a solid overview of how to handle some advanced TDD tasks that many other books gloss over.
The book begins with an introduction to test driven development. The authors clearly have a lot of experience (they wrote NUNit) and do a solid job of explaining why TDD can be an extremely valuable design tool. After introducing TDD the authors provide a quick overview of Refactoring by stepping through a sample application. Throughout the book the authors present semi-real life examples to make their point. The authors don't present and implement things in an idealistic way as some other books do, instead they refactor and test as they would a real application.
The chapter that I was looking forward to reading the most was TDD with ADO.NET. Many other TDD books gloss over how to use TDD when a database is involved. Additionally many TDD proponents believe that TDD should not involve the database. The authors present a Media Library example to demonstrate how to use TDD with ADO.NET. The architecture of the sample application is based on datasets. To test the ADO.NET code the examples compare the data retrieved from the database in a dataset with the in memory dataset containing the expected values. Although the examples do offer some very good insights into ways in which developers can use TDD with ADO.NET I was hoping for more. I would have loved to see some more examples including some other architectures based on custom business objects and a domain model. Even so, I got a lot out of the chapter. If nothing else it was good to see that the way I was implementing my tests wasn't totally off base.
The books goes onto cover topics such as TDD with web services, Implementing Customer Tests (with FIT), Transactions, and more. Overall the books offers a lot of valuable information to those getting started with TDD.
As I was reading the book I took notes on my HP 4350. The notes can be found below:
Intro/Overview of TDD
- Never write a line of code without a failing test.
- Eliminate Duplication
- Write a test list 15-20 Minutes per 4hr task
- Test list verifies requirements and Describes completion criteria
- Red/green/refactor
- Focus on what the class does not how it's implemented
Refactoring
- Refactoring improves structure of existing code
- Refactoring makes longterm software ownership less painful
- Need up to date tests before refactoring
- Tests provide safety nets for refactoring
TDD with ado.net
- Typed dataset for populating test database
- Leave relationships off typed dataset to increase testability off individual entities, other tests will verify relationships
- Ideally only one test should fail because of a problem. However this is not always possible when testing db apps, it should remain a goal.
- Dataset based examples not as valuable as custom object examples.
- Tests for entities, relationships and utilities.
- Naming of test classes with Fixture, test method names not testdox'able.
- Organize tests by use, in separate assembly.
- Very useful to have suite of tests that can test/validate db schema and let us know when a change causes problems
TDD with web services
- Write tests to minimize the dependencies
- Want failing test to pinpoint the problem in code
- Isolation reduces debugging
- error checking in stub.code should only be done if the cost outweighs the benefit
- Write dto using schema and xsd.exe
- Map dataset to dto via 'assembler'
- Test in isolation and then introduce database
- Database fixture inherits from implementation fixture
Customer tests
- Allow client to define requirements in an easy to use format/language
- Automated to facilitate feedback
- Fit
- If fit tests require code changes to adapter class what is the real benefit over NUNit?
- Write customer tests first
Transactions
- Use transaction to rollback db to pre test state
- Transaction manager on thread, classes that hit db check if they should join existing transaction or create their own. Done via command pattern.
- Adapters to convert xsd.exe classes into bindable objects
- Separate web code as much as possible to increase testability of the code.
I recently came across a couple blogs that had “What am I reading” sidebars. One of the blogs had about 10 books in the list. And to think I've been limiting myself to one at a time.
Currently on the Reading block...
How many books do you read at one time?
The complex answer is that the values espoused in the Agile Manifesto (and by XP in particular) resonate with me at an emotional level ("XP ain't out there, it's in here".) My personal values certainly include feedback, communication, courage and simplicity and I enjoy working with others who feel the same. I find it b