CODEWITHSUNDEEP
unit-testingtestingtddintegration-testingbdd
user82216
user82216

Reputation:

Testing - nomenclature

Classes are often tested by using tests written in the following sort of syntax, which is provided by a large set of testing frameworks (e.g. Ruby's Unit::Test; or as in this example, MiniTest):

class TestLolcat < MiniTest::Unit::TestCase
  def setup
    @lolcat = Lolcat.new
  end   
  def test_that_lolcat_can_have_cheezburger
    assert_equal true, @lolcat.i_can_has_cheezburger?
  end
end

or instead by using tests written in a second sort of syntax, which is provided by an overlapping set of testing frameworks (e.g. RSpec; or as in this example, MiniTest again):

describe Lolcat do
  before do
    @lolcat = Lolcat.new
  end
  it "must be able to have cheezburger" do
    @lolcat.i_can_has_cheezburger?.must_equal true
  end
end

(There are probably other syntax families which are also suitable for testing class methods and attributes, but these are the two I'm interested in.)

What I want to know is: what is the correct name for each of these two syntax families?

If you want to know more about why I'm asking, see below the line.

The reason I'm asking this question is that searching the Web has not yielded an obvious consensus. For instance, the MiniTest documentation refers to the first syntax above as "unit test" syntax and the second as "spec" syntax. By contrast, Michael Hartl describes class method and attribute tests written in the second sort of syntax as "unit tests". Where tests written in this syntax test higher-level functionality that results from the interaction of multiple classes, he calls them "integration tests".

I've also seen people describe the first and second sorts of syntax as "Test::Unit style" and "RSPec-esque", respectively, or "TDD" syntax and "BDD" syntax. Other names for the second sort of syntax include "'should'-like syntax" and "it syntax".

My understanding (which vaguely suggests Hartl is correct) is as follows:

However, this still doesn't entirely clear things up. Evidently, I'm no expert in the nomenclature of testing practices, test types or test syntaxes. The best names I've been able to come up with for the two types of syntax I've given examples of above are, "'assert' syntax" and "'it ... do' syntax", respectively. Unless these names are in widespread use, I need your advice, fellow StackOverflow users!

Upvotes: 3

Views: 1132

Answers (4)

Lunivore
Lunivore

Reputation: 17602

It might clarify things if we shared a bit of history about BDD and TDD.

Back in 2003, the unit testing framework of choice for TDD was JUnit. Dan North started writing JBehave as a replacement for JUnit, using "should" instead of "test" - so, BDD syntax. Now that doesn't look very similar to what you're doing (and what RSpec does) in Ruby, but nonetheless, RSpec was created as a Ruby version of the same thing. JBehave never nested testing code; it just had "should" for unit-level examples and then some other gubbins for running full-system scenarios. Dan migrated the scenario runner to Ruby, where it became the RSpec story runner, then eventually Cucumber.

So, the "it... should" syntax is definitely unit-level BDD. Most people are familiar with BDD as full-system scenarios, but it isn't where BDD started. Nowadays BDD isn't really one practice; it's a mini-methodology that goes right up to project visioning - just in case you come across anything confusing like that. And JBehave 2.0 was rewritten to work with scenarios and steps, and lost the unit-level testing along with a mocking framework, because JUnit and Mockito worked well by then. But, nonetheless, that's where "should" started.

Now... as soon as you use "must" instead of "should", you lose the sense of uncertainty that "should" provides. Using "should" allows you to ask lots of questions, the most important of which is "should it?" So, anything which uses "must" instead of "should" isn't really BDD syntax any more; it's a hybrid.

Incidentally, we try to avoid the word "test" when we talk about BDD, so they're not unit tests written in the course of testing; they're examples of how a class will behave, written in the course of designing the code.

Upvotes: 3

ewernli
ewernli

Reputation: 38605

When dealing with software, one need to distinguish between "what" and "how": what should the program do, and how does it work.

IMHO, it is important to keep in mind the difference between the two during all phases of development. This distinction supports several principles, e.g. coding against interface, responsability-driven design, design by contract and assertions, and unit testing.

Alas, it is not always so easy to decouple the two notions. Classic examples such as sorting are easy to deal with: several algorithms exist to sort (the how), which all result in a sorted set of elements (the what) that can be easily expressed as an assertion, contract, invariant. For business code, the situation can become less clear.

I belive the two syntax achieve foundamentally the same things, but the 2nd approach facilitate thinking in term of "what", rather than "how". Let's consider the two statements:

assert value % 2 = 0

value should be even

They enforce the same invariant, but the 2nd one puts more empahsis on the "what", and is more human-readable.

Smalltalk uses for instance the should wording but tests are imperative code like in Ruby.

SetTestCase>>testAdd
    empty add: 5.
    self should: [empty includes: 5]

Unfortunately, my digression still doesn't answer your question and was too long for a comment.

Upvotes: 0

Frank
Frank

Reputation: 1489

There are no globally accepted syntax names for test methods. Most unit testing tools encourage a certain convention, like JUnit encouraged to start all test method names with "test" which has now been made needless through the @Test annotation.

Most Unit testing tools suggest a certain convention on which developers agree. Test methods names have no syntax since the target audience are developers who should easily grasp what a test method does.

If you are looking for definitions in testing context have a look at the book "xUnit Test Patterns" by Gerard Meszaros. The author offers some clarification on different terms. His definition of "test doubles" has been referenced by several times.

Upvotes: 0

Johnno Nolan
Johnno Nolan

Reputation: 29659

I'm not sure there is an accepted definition for each.

I like to think of them in these ways.

the mini-test version is more of an assertation

the rspec version is more of a specification

The latter was concocted to steer you away from the emphasis on 'test' and more to driveout the requirements from a stakeholder point of view.

Upvotes: 3

Related Questions