use or practice.” 
Within the body of test cases we make 'assertions' about our code. Assertions are defined as:
"A confident and forceful statement of fact or belief.” 
The language of testing shapes our thought process into trying to answer the question "How does my class work, and is it right?" Instead we should be answering the question "What does my class do?" As Bob Martin has said, "Testing is about Specification, not Verification.” 
If I Only Had a Hammer!
Language this not the only place where our tools hinder our progress. Most integrated development environments that support xUnit provide some 'helpful' features for generating test cases, such as creating one test case per class and creating one test method for each (and every) method in a class.
Now these features can be helpful in the beginning when a developer is still new to the syntax of a test case. However, if (mis)taken as a best practice we learn bad testing habits.
Testing internal state and private methods are another bad habit. The externally visible behavior of a class has nothing to do with its internal state. Testing private methods is a test smell; it usually indicates that a class is doing too much and should be broken into several classes, each with their own behavior, tested independently.
Test organization can be a source of another test smell. As the number of test methods in test classes increases, it becomes too large to manage, maintain, and understand. A class may have behavior in several different scenarios, each scenario with many distinct behavior. Tests should be organized by functional context not simply by class name.
The language and tools of unit testing limit the activity of TDD to one of verification. BDD provides new tools, approaches, and language to approach software development from a different angle. One such BDD tool is rSpec, written in Ruby.
Behavior Driven Development Using rSpec
The rSpec project has been blazing the BDD trail by leveraging the flexibility of Ruby to create a domain specific language around the specification of behavior.  An example:
describe Stack do
@stack = Stack.new
it "should be empty after construction" do
@stack.length.should == 1
Several things to note about this example;
- rSpec requires that you describe what behavior is being expressed. You may no longer leave empty the descriptions passed to assert().
- We 'describe' a class, or a class in a given context. Specifically we describe the behavior of a class.
- We use the word 'should' to specify class behavior. The choice of 'should' over 'shall' or 'must' is both subtle and important. It allows the reader of the spec to ask, "Well, should it?"
- We again use the word 'should' when declaring our expected outcome.
Compare the same example to a xUnit test (in this case Ruby's Test::Unit).
class StackTestCase lt; TestUnit::TestCase
@stack = Stack.new
def test_empty_stack do
The mechanics of both examples are the same; setup the scenario and then declare some expectation. However, nothing in the latter example leads you to think about behavior. rSpec gives us the language to reason about the behavior of the class.
rSpec, because of its Ruby underpinnings, has an advantage for language and syntactic flexibility. However, if you're not using Ruby, all is not lost. There are several BDD frameworks for both Java and .NET.
However, the easiest one to use is the testing framework you probably are already using, xUnit. Try this experiment on your next test case:
1. Name your test class