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:
Vanderbilt University, a large private school in Tennessee, is enforcing rules that require all student groups receiving on campus funds to open up membership to anyone - including officer positions (story on NPR). Naturally, this is of great concern to Faith-based organizations in particular: one can easily imagine a group of atheists gate-crashing a meeting and electing their own leader to be the President/Chair/Grand Poobah of the _ <insert religion> Association_.
For years I've had problems with SSIS deployments to production. In fact, I completely abandoned SSIS packages because it was so difficult to deploy to production (in SQL Server 2005): I always ended up with errors that would require me to hand-edit the file and hard-code paths. That, despite the fact that my config files have the database connection strings and file paths in them. And despite the fact that my packages usually work fine on the test server but fail in production. After years of this problem, it suddenly occurred to me that one piece in particular is probably at fault. But given that I do not have access to production such that I can investigate, it will always be a hypothesis: using a template that sets various properties with the help of variable expressions.
Assuming that you are already sold on the notion of automated testing, it can be useful to put a little thought into how projects will be setup. There are many approaches to this; my approach is based on experience, the wisdom in xUnit Test Patterns, and standard coding best practices. I will try to keep this language agnostic, though my examples will be in C#.
This past Wednesday I was proud to take part in a banquet event on the theme of "Embracing Unity," sponsored by the non-profit Grand Prairie Unity Coalition, of which I am a new Board member. This was the 7th such banquet, which brought together people from many like-minded organizations, local / county / state politicians, and most importantly, around 40 students and family from the local school district. The organization's mission is to provide education and opportunities for cross-cultural association to the Grand Prairie community, and that mission was admirably pursued with Wednesday's event.
"The best way to attack the essence of building software," Dr. Brooks writes, "is not to build it at all." (p222). With this he introduces a brief discussion of the importance of code reuse, and of its challenges.
Lately I've been wondering if the Keystone Pipeline isn't more of a NIMBY than anything else. NIMBY stands for Not In My Backyard, and is typically a reference to well-off individuals and communities decrying the building of some unwanted facility "in their backyards" — that is, just down the street or in the general vicinity. For example, in St. Paul, MN there has been an outcry over plans for an electricity-generating incinerator (dead link removed; SF 2025 removed) on the edge of the neighborhood in which I used to live. Now, that is a blue collar neighborhood, not particularly well-off. A classic NIMBY situation is where the well-funded are able to fend-off development, pushing it to some location where the project's opposition are not so well funded. Thus, the NIMBY-effect becomes a matter of eco-justice: the poor end up saddled with the polluting plant, though the rich derive at least as much benefit from the project.
Recently I began carving out some time for using CruiseControl.Net in earnest. The book Continuous Integration in .Net was, and I'm sure will continue to be, of great help. Nevertheless, I think it will behoove my own memory, and perhaps help a few others, to record some notes on a few practical details.
