Sometimes you need to go back to the basics - including basic technology. In this case, I mean sticky notes. Yes, they are a remarkable form of technology. I like doing everything the digital way. I abhor using paper when not necessary, because of the waste factor. Although I love the idea of note cards for user story development, I've been thankful that they are impractical for my development team. But, I think it is time to heed good advice.
We build a lot of console applications, and Windows services, that process inbound and outbound files in one way or another. Most depend on configuration data and some load (or unload) business data from a database, in addition to accessing the files. Testing these has always been a chore, to say the least: configurations change, data are deleted, and there's never enough time. After building a few rudimentary tools that have helped, necessity, and Agile Testing: A Practical Guide for Testers and Agile Teams, has convinced me that it is time to get serious about system/integration test automation, just as I did about unit test automation a few years ago. This is the first of a n-part series of posts on this process
using Application Settings in a .Net project, you find that there are so many entries that some organization is needed.
create custom, serializable data types for logical groups of settings.
Need to move rows up and down, and from one table to another, in an HTML page.
careful use of jQuery. There are probably many different solutions already out there, but I wanted to learn how to write one for myself. Key functions: closest, detach, append, prev, next, before, and after.
Wherein I record a few tips on the use of System.ComponentModel.DataAnnotations, which I am likely to forget if I do not need to think about them again for some months…
Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce
I did not realize how much I still have to learn about writing good object-oriented (OO) code, and about hewing to a tight test driven development (TDD) methodology, before I read Growing Object-Oriented Software, Guided By Tests. My education in OO and unit testing has been largely theoretical, with no time spent directly learning from experienced OO programmers; my best mentor was a COBOL coder. Books like Design Patterns: Elements of Reusable Object-Oriented Software ("Gang of Four"), Patterns of Enterprise Application Architecture, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Xunit Test Patterns: Refactoring Test Code, and others are wonderful but have few detailed real-world business-case examples.
Moles is a powerful and useful framework for unit testing. Or was. But even then, it was overused (at least by me). But no more!
The first clue that I might need to walk away from Moles was the recent difficulty another developer was having in trying to get a unit test project up-and-running on his computer. I had installed what was current in early 2011, and he had installed the current version from last 2011. Turns out there was a significant change – the config file no longer worked. We had to update the assemblies correctly on my machine, rebuild many times, and fool around with manually removing some assemblies. It got confusing and messy. I suppose that's why MS still labeled this version as < 1.0.
Here’s an interesting scenario: I have a Linq-to-Entities query that is giving me no results when performing a system test, but when I look in the database, logically there should be results. Better yet, the unit test passes. How can that be?
A common challenge for development teams is remembering the names for all of the different servers in an enterprise environment when the server naming convention is either not descriptive ("Deathstar", "Falcon", "XWing") or obscure ("abcDBS001", "abcDBS002", "abcWEB01"). The Star Wars names suffer from an obvious problem of mapping description to purpose. Those obscure names are commonly used to help distinguish between dozens to hundreds of different servers in an enterprise. Arguably they are helpful to the infrastructure team as they manage this motley collection. But for a developer, remembering if "abcWEB01" is the test web server or prod can be challenging; even when remembered, it would be simple enough to overlook or accidentally type "abcWEB04".
Historically I've advocated naming test methods after the method under test, in order to help find the tests when you need to modify them. Growing Object-Oriented Software, Guided by Tests has shown me that this is a relic of a code-first mentality rather than good application of test driven development, primarily in the section "Test Names Describe Features" (ch 21). "Test driven" development implies that we do not know the name of the method we're going to test. But we do know the functionality (feature) that we are going after, and that knowledge should be used when writing out a test name. For example:
