Is this statement true?
Friday, February 27, 2009
Labels: TDD
Labels: TDD
"Not all good programmers practice unit testing or TDD, but all who follow a test driven development approach are good programmers."
Susquehanna Valley Flash/Flex UG tonight 2/24
For those of you in the Lancaster, York, Harrisburg area, the second meeting of the SV Flash/Flex User Group is tonight. Details are at http://groups.adobe.com/posts/d36acddf59 Tonight's topic: 3D in Flex!
TDD, BDD, Unit Testing, Top-Down, Bottom-Up, Wus Up?
As developers, we all have pretty much the same goals in mind. In general, these are to write good software quickly. There are many definitions of what is good software, but for our purposes let's define it as software that (1) has a low number of defects, (2) software that can be delivered in time, (3) software that can adapt quickly to changing requirements, and (4) software that can be easily understood by peers (clean and well-designed). To that effect, however you get there is OK. Whether you use some form of automated testing, manual testing, or Kung Fu. If the end result is "good software", why should it matter?
The above shows two different approaches to testing. In addition, they test two different layers. The first one is a BDD-like approach to verify the dog's behavior by exercising various methods on the Dog object together. It tests how these methods interact. This is loosely referred to as interaction testing, behavior testing, or integration testing. This may support a use case requirement and be something that a customer may also understand. Whereas the second one (a clear unit test) targets a piece of code, a single method, responsible for some imaginary computation. This computational unit test is not intended to test how the object interacts with other objects; it's focus is on what the method is doing and how it affects the component's state. The method under test may not deliver any direct value to an end-customer, but it's role within the software may be critically supportive. To assume that this method will be thoroughly tested by some other object higher up in the stack may lead to defects. The best way to test something like this is in isolation and pass it a variety of test data that will exercise the method in both expected and unexpected ways.
Lately, there's been a lot of negative attention drawn to unit testing. The negativity seems to be indicator of a lack of understanding of where unit testing fits in, how it can be applied, and some weird assumptions that unit testing is some golden beacon. Many anti unit test folks talk about a "false sense of confidence" that comes along with unit testing. For us, the more tests we write, the more we realize what is missing. Frequently, confidence goes down as the number of tests goes up. We attribute this to the cognitive process of reasoning about an application under test. For us, this is a discreet value emerging from unit testing. We've found that tests help us to understand what needs to be written and frequently points out gaps, errors, and omissions. Others don't need or don't use unit testing the same way - they seem to feel it's a waste of time. Why should we judge your process if what you produce is "good"?
We think there's some definition problems, too. People seem to get confused about unit testing and TDD. Likewise, there's confusion about BDD and unit testing. To be clear, both TDD and BDD are processes. Unit testing is a testing target or technique, not a process. MXUnit and cfSpec are tools that support processes and techniques. MXUnit is a test harness that can be used to run many different kinds of tests. For example, if you have a BDD package you could use MXUnit to support both your TDD and BDD efforts:
function dogShouldSitWhenTold(){
var myRadBdd = createObject('component','com.foo.RadBDD');
var dog = myRadBdd.create('com.bar.Dog')
.should()
.sit()
.when()
.iSaySo();
}
function myComplexAlgorithmNeedsToWorkCorrectly(){
var algo = createObject('component','com.foo.Algorithm');
var a = [1,2,3,4,5,6];
var actual = algo.performSomethingComplex(a);
assertTrue( actual.isRad() );
}
The point is, that unit testing and interaction testing, in clear cases like this, show how two different approaches to testing can be used to address different aspects of software. Also, it shows how these two types of tests can be run using one tool. MXUnit provides you a platform to build the kinds of tests that best suit your development needs. MXUnit does not dictate how you should build tests, in what order they should be tested, what assertions to use, or if you should test units or object interactions. Whether you write your tests first or last, whether you express your tests as focused unit tests or interactions or both, or whether you prefer BDD to TDD or Role-Your-Own-DD, different tests and testing approaches address different aspects of software systems. Further, some testing approaches fit better into differing development cultures. Some projects may require more unit testing; others more functional tests, and yet others only manual testing may be required. It's up to you to decide what works best for your projects and how best to achieve the goal of "good" software.
MXUnit is committed to providing the best testing platform possible for ColdFusion developers.
Test and be Happy 
the guys at mxunit dot org.
Connecting SQL Server 2008 to ColdFusion
Tuesday, February 10, 2009
Labels: SQL Server
Labels: SQL Server
When I installed SQL Server 2008 at home, I had no problems with the installation or with hooking ColdFusion into it. At work, a different story. Here are the steps I took, the errors I encountered, and ultimately how I was able to get it all working.
Installing SQL Server
When it prompts you for an install directory, it'll be something like "c:\downloads\x86". do not just accept this as the default. Add "\sqlserver2008" or something onto it, such that your destination is c:\downloads\sqlserver2008\x86. You run the installer as normal. It'll probably prompt you to install the latest version of .net. This will take a while. You'll need to reboot. When this happens, go through the normal install rigamarole (click Next a dozen times, etc). The first roadblock I hit was this message: "The SQL Server 2005 Express Tools are installed. To continue, Remove the SQL Server 2005 Express Tools." So I hit the Back button a few times, but there was nothing in the "Choose components" box indicating sql server 2005 Express Tools. Off to google I went, and found this right away. So, fix #1 was to uninstall SQL Prompt. Done. Moving right along.... The rest of the install went well. One thing though: When I had to chose the instance name, it wouldn't let me choose the Default Instance, saying I already had an instance with that name. So I used "mesher" as the instance name. This is important for later.
Connecting to ColdFusion
At a minimum, you'll need to enable TCP connectivity for sql server.
This is simple:
1. Start -- All Programs -- Microsoft SQL Server 2008 -- Configuration Tools -- SQL Server Configuration Manager
2. in the "SQL Server Network Configuration" section, find your "instance" and look for tabs for Protocols. Shared Memory should be enabled, but the others probably won't be. Right click on "TCP/IP" and enable it. Do the same for the "SQL Native Client" section.
At home, this is all I had to do to get CF talking to SQL Server 2008. At work, this is where the fun started.
I initially tried setting up a DSN in CFAdmin, with the server name of "bltr-mesher2\mesher", port 1433, but kept getting the "The requested instance is not running or isn't valid" error message from CF. This part bears some detail. Note that I used "\mesher" to denote my "mesher" instance. Remember... it wouldn't let me use the default instance when I installed. So right about this point, I was stumped. I KNEW the server name was right. So it must be a port problem. I didn't have any port problems when I did this at home, and as far as I knew, sql server always ran on port 1433. So what gives? I opened a cmd prompt and ran netstat, but didn't see anything suspicious. I tried removing the instance name, tried changing the port, but no luck. Back to google where I found Matt Woodward's post, about SQL Server 2005 and CF. The port settings described in this post were part of my problem. So I went to TCP/IP in the config manager, right clicked, selected "properties", then the "IPAddresses" tab, and sure enough, I had 0 in the "dynamic port" boxes and the port numbers were screwy. (When I installed 2008 at home, I had no such port BS to deal with.)
So I blanked out the dynamic port boxes, added "1433" for the port in IPAll, and restarted.
Still no dice. WTF? I played around with various things, googled and whatnot, telnetted in at port 1433 (worked fine), but couldn't figure it out. Finally, on a whim, I removed the instance name again from the "Server" field in CFAdmin. And it worked. I have no idea why this works. I'm sure there's a perfectly valid reason. I just don't know it.
Summary
1. When I got the error about SQL Server 2005 Express tools, I uninstalled SQL Prompt
2. When I chose my instance name, I wasn't able to select the Default instance. If you can select the default instance, do so unless you have a good reason for not doing so.
3. You have to go into SQL Server Config Manager and
a. Enable TCP/IP
b. Blank out dynamic ports and set your port number to 1433
4. After all this, if you're still having trouble connecting CF to SQL Server, and you've used an instance name, try removing the instance name from the DSN "Server" setting.
Subscribe to: Posts (Atom)
