On Feb 22, 2008, at 12:01 PM, Matthieu Riou wrote:
I don't see that. They are different in the way you write them as
BDD is
much better at expressing the intended behavior. However down the
road,
they're both used to test your code and nothing else. So what is the
difference in purpose?
If you're looking at assert vs should, then those are two different
ways to formulate test cases. That's separate from how they're being
used.
If you're writing specs using asserts (which RSpec allows), those are
still specs. If you're writing tests using should (which can be done
with some difficulty using RUnit), those are still tests. You're
mixing APIs, but not changing the manner in which they are used.
Let's say in Buildr 1.3 the build task no longer executes on the
project in the current directory. If the test fails (on any
framework) then we know the code is broken and needs to be fixed.
That's what tests do.
But what if the test passes? Then clearly the code is correct, it
complies with the test. But it doesn't comply with the spec, and it's
the spec that tells us the code is incorrect and in addition the test
is broken.
Here's what the specification says:
build task
- should execute task for project in current directory
- should not execute task for projects in other directory
Note that the specs don't have to test anything, I just think it's
much more convenient to always use RSpec for the tests, given that I
would like to have a spec of anything before we have a test for it
(spec->test->code). We could in theory have unit tests in /test and
specs in /specs. But clearly only one of those would provide the
formal specification for what the software does, and that's a
fundamental difference.
Assaf
