Last week I proposed a structure for unit test that follows the pre-condition, action, post-condition workflow. Basically what you would see in a Use Case document.
The result of this structure when applied to a general NUnit class is that we will end up with our pre-condition and action in our setup method and our post-condition asserts in our test methods.
The problem with this is that sometimes this doesn’t always fit what we are trying to do.
One of the recurring reasons I hear from people for why they are not implementing unit test in their code is because it takes too long. On one level I get that. But, my experience tells me that the real problem is more likely that they just don’t understand enough about how to implement unit testing to be able to do it well.
This is like knowing you are supposed to “eat right” and “exercise” but not having anyone tell you how to do either in such a way that you can maintain the habit.
A long long time ago, in what seems now like another world, I worked for a company as a Clipper programmer. While I was there I heard this story about a lady named Debbie.
I was told that Debbie was a programmer who used to work for this company. Debbie was a lazy programmer. She worked harder at avoiding work than if she just did the job she was supposed to do.
Several years ago, long before the community was actively talking about Test Driven Development, I worked for a short time at a company as a “bug fixer.” That was my role. They had hired me because they had some software that was “basically done” but “had some issues.” It should only take a few weeks.
The first thing they needed me to fix was that the website was supposed to send out email. It turns out it was a configuration problem. But they were so impressed (“the last guy we had in here spent two weeks on that problem and still hadn’t solved the problem.”) that they gave me more and more bugs.
On Monday 2/17/14 I gave a presentation at the CT .NET User’s Group on using Selenium and NUnit to test your web application. The following is a list of resources from that presentation:
The IF statement we looked at on Tuesday was pretty tame compared to the WHILE construct. Actually, the main thing you need to keep in mind is that WHILE is all you have. There is no such thing as a FOR loop or a DO WHILE loop. So, you have to force WHILE to do those for you. The basic syntax of WHILE looks like this:
SQL has long had the ability to specify that a value is NULL even if it is a primitive type, but the only way you could have a NULL value in VB.NET is if you were dealing with an object. That is, until .NET 2.0
Yesterday, I spent the bulk of the day converting a DataList to a ListView. I thought I’d spend a little time relating the process for those of you who might be interested in doing the same.
Several weeks ago I presented jQuery at the DotNet User’s Group in Connecticut. As part of that presentation, I mentioned that I handle errors from my WebServices in a slightly different way than what most authors teach.
Many times in our queries, we aren’t looking for an exact match. We are looking for one string that exists in another. There are a couple statements available to us that will allow us to do this. The first of these is the LIKE statement, and if you are familiar with DOS or the Linux equivalent, this should look familiar to you. The most common usage of LIKE looks like this: