I've been developing a number of applications in Ruby recently. One of these was ready for a Rails upgrade so I thought, let's go all the way to 2.3.5 (from 2.1) and see what happens.
Big Mistake!
Or so I thought!
What happened? My tests failed! Not only did they fail, the exception comes directly from the autorunner.rb class of the test-unit gem. Not from one of my classes. My code isn't touched!
Limited help on the sites...
Immediately I lept for my browser and started googling. Everything I turned up was full of conjecture and appeared to land on the "thoughtbot/shoulda" gems. But I don't use them, so they weren't causing my problem.
It turns out the cause was right in front of me. The error is coming out of the test-unit gem. Not from my code. Not from rails.
In Rails 2.3.5 (and maybe before), Rails introduced their own test-unit and started using ActiveSupport::TestUnit instead of Test::Unit::TestUnit.
So what was happening?
The test-unit gem is taking precedence and wreaking havoc.
The Solution!!!!
Uninstall the test-unit gem.
Tuesday, March 23, 2010
Sunday, July 12, 2009
TDD Is Great! But Only When Done Right...
Test Driven Development (TDD) and its closely related kin Behavior Driven Development (BDD) are relatively new kids on the block (only a few years old) and are taking the testing world by storm. Why? Because they are logical, simple, place testing into the proper part of the development schedule, and allow us to verify our applications performance.
Unfortunately, they are not being taught properly.
LEARN TO DO TDD & BDD PROPERLY
When you read a blog entry or book that describes TDD or BDD, they typically use a phrase like "First write your test, then code to pass the test". That's fine, but it's only a partial solution.
Why is it only a partial solution? Because if you do thus, you are only testing the Sunny Day Solution. You need to test the Rainy Day Solution as well. If you don't know what the difference between the Sunny and Rainy Day Solutions are, you don't properly test your systems. Don't feel bad if you're in this category. Most developers and even large development teams don't test their software properly.
So what do I mean when I say test the Rainy Day Solution? Let's examine this in terms of a system I put together in 2002. In 2002, I led a small team as we implemented an NFS front end to a database backed file server. In all respects it was a normal NFS server, except for storing it's file index in a mysql database.
So let's look at how TDD (or BDD) would be used for this (paraphrasing the common TDD example of an object contains a value)
1) Define my test.
Ok. The test defining the requirement is that all file requests have a file name. (code is left as an exercise for you based on your favorite tool)
2) Now write the code to pass the test.
...
FileRequest fileReq = channel.receive();
If (fileReq.fileName == null) {
throw new FileNameMissingException();
}
....
Great. We've written our code to pass the test and throw an exception if we don't pass.
But what is a valid file name? If you read the NFS spec carefully, a valid file name can be a zero length string. Not typically something that would ever be touched in a requirement spec (unless you have a FAT or 8.3 file system).
So the problem is that it's not enough to just write the Sunny Day case, but you need to define and test all cases. Now before you start thinking this is impossible, you need to recognize this is a finite set of tests over 99.9% of the time. If you add bounds, format, and Magic Value testing to your requirement test, you have 99.9% of the teats for your requirement.
So don't just wrote your code to match your requirement test as TDD (and BDD) teaches. Build your full set of tests for good and bad situations, then write your code.
Unfortunately, they are not being taught properly.
LEARN TO DO TDD & BDD PROPERLY
When you read a blog entry or book that describes TDD or BDD, they typically use a phrase like "First write your test, then code to pass the test". That's fine, but it's only a partial solution.
Why is it only a partial solution? Because if you do thus, you are only testing the Sunny Day Solution. You need to test the Rainy Day Solution as well. If you don't know what the difference between the Sunny and Rainy Day Solutions are, you don't properly test your systems. Don't feel bad if you're in this category. Most developers and even large development teams don't test their software properly.
So what do I mean when I say test the Rainy Day Solution? Let's examine this in terms of a system I put together in 2002. In 2002, I led a small team as we implemented an NFS front end to a database backed file server. In all respects it was a normal NFS server, except for storing it's file index in a mysql database.
So let's look at how TDD (or BDD) would be used for this (paraphrasing the common TDD example of an object contains a value)
1) Define my test.
Ok. The test defining the requirement is that all file requests have a file name. (code is left as an exercise for you based on your favorite tool)
2) Now write the code to pass the test.
...
FileRequest fileReq = channel.receive();
If (fileReq.fileName == null) {
throw new FileNameMissingException();
}
....
Great. We've written our code to pass the test and throw an exception if we don't pass.
But what is a valid file name? If you read the NFS spec carefully, a valid file name can be a zero length string. Not typically something that would ever be touched in a requirement spec (unless you have a FAT or 8.3 file system).
So the problem is that it's not enough to just write the Sunny Day case, but you need to define and test all cases. Now before you start thinking this is impossible, you need to recognize this is a finite set of tests over 99.9% of the time. If you add bounds, format, and Magic Value testing to your requirement test, you have 99.9% of the teats for your requirement.
So don't just wrote your code to match your requirement test as TDD (and BDD) teaches. Build your full set of tests for good and bad situations, then write your code.
Friday, July 11, 2008
Exactly what do they do in Summer School
My son doesn't speak. Unlike children who don't speak because they are mute or have difficulty speaking due to deafness or another reason, my son doesn't speak by choice. He makes some sounds and uses a few words, but instead of speaking, my son uses sign language to communicate.
Now understand, my son is seven years old, has Down's Syndrome, and he has personally chosen this form of communication.
His summer school teacher uses spoken language and doesn't know sign language. Neither do the aides in her class.
Now with all of this, we have established goals for school. These are things we expect him to do or accomplish within a given period. Typically these are what you and I would consider very simple, but they hide a great deal of complexity, eye hand coordination, and fine muscle control.
His recent communication goal is :
my son "will identify numbers 1 - 20 on flash cards when requested, and give the sign for numbers 1-10 with 80% accuracy as measured by the special education teacher by" a given day.
This is actually a very low goal as far as we are concerned. My son communicates with well over 300 signs (far beyond what I know) and he has very little trouble getting me, my wife, his siblings, or most people to understand what he wants or needs.
SO IMAGINE MY SURPRISE WHEN I RECEIVED HIS REPORT CARD AND READ:
"Though none of the summer teachers knew sign language prior to the beginning of the summer session, letter and number signs were practiced with the aid of a book on sign language. (My son) seemed amused at our attempts to communicate with sign language."
My son is very tolerant of people when they try to communicate with him so It had to be really bad if they were amusing him.
Now understand, my son is seven years old, has Down's Syndrome, and he has personally chosen this form of communication.
His summer school teacher uses spoken language and doesn't know sign language. Neither do the aides in her class.
Now with all of this, we have established goals for school. These are things we expect him to do or accomplish within a given period. Typically these are what you and I would consider very simple, but they hide a great deal of complexity, eye hand coordination, and fine muscle control.
His recent communication goal is :
my son "will identify numbers 1 - 20 on flash cards when requested, and give the sign for numbers 1-10 with 80% accuracy as measured by the special education teacher by" a given day.
This is actually a very low goal as far as we are concerned. My son communicates with well over 300 signs (far beyond what I know) and he has very little trouble getting me, my wife, his siblings, or most people to understand what he wants or needs.
SO IMAGINE MY SURPRISE WHEN I RECEIVED HIS REPORT CARD AND READ:
"Though none of the summer teachers knew sign language prior to the beginning of the summer session, letter and number signs were practiced with the aid of a book on sign language. (My son) seemed amused at our attempts to communicate with sign language."
My son is very tolerant of people when they try to communicate with him so It had to be really bad if they were amusing him.
Monday, July 7, 2008
This is what a college degree gets you...
I'm so glad I have a college degree (I actually have 2, a BA and a BS, so I'm a Bad A** at Bull S***!).
But what did that investment get me?
It allows me to explain exactly why, ala Bernoulli's Principal, I keep getting showered with milk every time I put the lid on my kids sippy-cup.
What did my investment get my kids?
They know enough to pull out the straw first.
Apparently I'm not smarter than a 4 year old, let alone a 5th grader.
But what did that investment get me?
It allows me to explain exactly why, ala Bernoulli's Principal, I keep getting showered with milk every time I put the lid on my kids sippy-cup.
What did my investment get my kids?
They know enough to pull out the straw first.
Apparently I'm not smarter than a 4 year old, let alone a 5th grader.
Thursday, June 19, 2008
When is the last time you really spoke to your computer?
If you're like most computer users, there have been times when you have spoken to your computer in anger. Yelling obscenities at it when it deletes your files. Screaming when error messages pop up. Grumbling when web pages take too long to load.
There are even times when you speak to your computer like it's a little child. Urging it to complete it's tasks. Begging it to let you do something you think you should be able to do.
But what about sitting down and talking to your computer and having it actually do what you ask?
We see it all the time on TV and in the movies when our favorite characters say "Computer, ..." and the computer does some work and responds. Why aren't we doing this ourselves? Voice Recognition technology has been publicly available since before 2000. For a price.
One recent advance in this area is the release of the Java Speech API version 2 (JSAPI2). Tools using this standard are available from Conversay, Inc. (http://www.conversay.com) for a relatively low price.
I started working with early versions of this toolkit in May 2007 and was amazed at it's capabilities. Since then, I've developed many systems that use voice recognition and voice synthesis along with many other technologies to create voice controlled hardware systems, voice communications systems, even voice controlled software.
It's been very liberating being able to speak to my computer instead of yelling at it in disgust, so I ask you:
When is the last time you really spoke to your computer?
There are even times when you speak to your computer like it's a little child. Urging it to complete it's tasks. Begging it to let you do something you think you should be able to do.
But what about sitting down and talking to your computer and having it actually do what you ask?
We see it all the time on TV and in the movies when our favorite characters say "Computer, ..." and the computer does some work and responds. Why aren't we doing this ourselves? Voice Recognition technology has been publicly available since before 2000. For a price.
One recent advance in this area is the release of the Java Speech API version 2 (JSAPI2). Tools using this standard are available from Conversay, Inc. (http://www.conversay.com) for a relatively low price.
I started working with early versions of this toolkit in May 2007 and was amazed at it's capabilities. Since then, I've developed many systems that use voice recognition and voice synthesis along with many other technologies to create voice controlled hardware systems, voice communications systems, even voice controlled software.
It's been very liberating being able to speak to my computer instead of yelling at it in disgust, so I ask you:
When is the last time you really spoke to your computer?
Friday, May 30, 2008
What superhero are you most like?
Your results:
You are Superman
Click here to take the Superhero Personality Test
You are Superman
| You are mild-mannered, good, strong and you love to help others.  |
Click here to take the Superhero Personality Test
Subscribe to:
Posts (Atom)