Unit Tests
There are 6 entries for the tag
Unit Tests
Man, I'm going to catch it for that title. Okay, let me get this out up front: this post is a hypothesis that I consider probable. That's why there's a question mark in the inflammatory title. Okay, asbestos underwear in place, let's continue.
The Hypothesis
Here's the logic flow for my hypothesis.
Unit testing (and its bosom buddy automated testing) provides substantial benefits when used regularly. These benefits are well-understood.
Ensuring or regularizing unit testing is the primary value proposition of Test-driven Development (TDD).
A majority of vocal unit testing...
Because Unit Testing is the plain-Jane progenitor of Test Driven Development, it's kind of unfair that it doesn't have an acronym of its own. After all, it's hard to get programmer types to pay attention if they don't have some obscure jargon to bandy about. UT is too awkward, besides being a state abbreviation in the U.S., so for this post (and, if it catches on, future posts as well) I'll borrow from the telco folks and call unit testing Plain Old Unit Testing.
The Best of all Possible Worlds
Part of my problem with TDD has been that it claims...
One of the most useful classes I took in college was an introductory statistics class that was intended to discourage Poli. Sci. majors from continuing in their course of study (I was one at the time). The interesting thing about the class is that it included study and analysis of research as a core part of the class. We learned how to put a study together, how to develop controls, and different formulas used to confirm whether we had statistically significant results or not.
So when Phil Haack announced that Research Supports the Effectiveness of TDD I was more than...
Bob Lee, creator of Google’s Guice project (the Dependency Injection framework for Java) has twice left comments here urging me to check out his talk introducing Guice. I resisted this because a) I don’t do Java and b) I figured I’d had enough with a later video recommended by Nate. This afternoon, I broke down and watched it and I’m glad that I did.
It turns out that the things that grated on me from the first Guice video I viewed came mainly from Kevin Bourillion—mostly unfair comparisons to alternatives and boosterism. Bob is very personable, open and seems honestly intent...
I can’t believe the potent response I’ve gotten on my posts about Dependency Injection. Ayende Rahien responded individually to each of my posts himself, which is more than a little bit intimidating all on its own and a couple of development heavyweights left comments directly. Nate describes Ayende’s posts as the cavalry arriving and links to a couple of other responses. All of these posts disagree with me, though a post by Aaron Jensen indicates that he’s at least willing to consider the possibilities.
All of this should have been foreseeable, really, as soon as I decided to publicly post...
Dependency Injection is a design pattern used to abstract a provider from the class using it. Specifically, the calling class assumes responsibility for managing the provider instead of the class being called. Data access is a classic example of a provider that can be injected into classes that use it. If you decide to implement the DI pattern in a data access project, the most common method of doing so is to add an interface parameter on the constructor of each class that needs data access.
A C# Example
A class that accesses data might look like this (if it were programmed...