Re: Where do we put specs: src/test or src/spec?

[Assaf Arkin]

On Feb 22, 2008, at 11:11 AM, Matthieu Riou wrote:

I agree about the significant difference although that's not really  
my point
(maybe that wasn't too clear). There are all kind of sources as well  
and
they all belong to src/main. The different between test and sources is
mostly that one is packaged and shipped and must be part of your  
runtime,
not the other. In that light spec and tests are strictly identical.

Buildr packages and ships both sources and specs.  You can tell  
RubyGems to run tests during installation, make sure it works on your  
environment.  You can consult the specs for things the docs/code are  
not clear about.  You can patch it locally and run the test suite (gem  
check -t) to make sure you're not breaking anything.

Likewise, I expect that in the future you'll be able to do similar  
things with specs, e.g. generate spec report alongside rdoc for your  
Gems, and I consider both essential part of the runtime.  I spend more  
time reading those than coding against them.

The distinction between main, test and spec is that conceptual:  
they're different parts of your codebase that serve different purpose  
and are used in different way.

The packaging distinction exists in Java for various reasons, but Java  
is not the only model we're trying to promote here.


Now if you wanted to do test/spec/java and test/junit/java that'd be
something else, which would make sense even if it would probably be  
easy.

We allow that, but I don't see why we would promote that by  
convention.  test/junit/java will also work on TestNG, so I wouldn't  
recommend coding the framework name in the path; likewise, specs  
written against RSpec can run on several test frameworks.

On the other hand, specs are fundamentally different from test.  If  
you have both in the same project you're still using them  
differently.  If you're packaging them for a language that supports  
that distinction, they're packaged and installed separately.

Again, not a distinction Java makes, but that distinction definitely  
exists in contexts that allow for it.

Assaf


Having spec outside of test would surprise me, specs are tests even  
if they
are different kinds of tests, they obey to the same packaging rules.

Matthieu

On Fri, Feb 22, 2008 at 10:24 AM, Assaf Arkin <[EMAIL PROTECTED]>  
wrote:

On Feb 22, 2008, at 8:50 AM, Matthieu Riou wrote:

I'd go for src/test because, even if specs are changing the way we
test,
it's still test. If tomorrow a new nice testing library comes up
with new
testing concepts are we going to create its own src/foo directory as
well?

BDD is significant, it's not another test framework that does thing
slightly different than the previous one, and these conceptual
evolutions don't happen frequently.  Not every other month, not even
very other year, that I'm just not worried about potential namespace
pollution.


BDD is significantly different from TDD.  First, you write a
specification of how the software behaves.  Then you fill it up with
test case that run against the implementation.  Then you write the
implementation to pass the tests.  TDD does only two out of these  
three.

I can tell you that 'local task should execute task for project in
local directory' because we have a specification that says exactly
that (build_spec.rb, line 21).  If the local task doesn't execute for
project in local directory, then the code is wrong and the test is
wrong (for not revealing it), but the spec is still right.  So you
patch the test, and you patch the code to pass the test, but you  
don't
patch the spec.  The spec is the behavior we agreed upon.

That is a significant different from unit tests.  Unit tests have
code, which may be wrong, and tests which may also be wrong, and
nothing that you can rely on to express what the right thing is.

When 1.3 comes out, we'll have one page on the Web site with the
formal Buildr specification generated from the files in the spec
directory.  If the specs, code, tests and docs are in conflict, the
spec is always right.  If we don't like the behavior, we change the
spec, but until we do that, the spec is right even if the tests are
wrong.

So there's is a significant difference between TDD and BDD, they're
not just two different ways to write test cases.  One writes formal
specifications, the other doesn't.

Assaf



Matthieu

On Thu, Feb 21, 2008 at 1:20 PM, Victor Hugo Borja <[EMAIL PROTECTED]

wrote:

Another one to
look at is JBehave, although I can't tell if they have any
conventions for directory structure.


Haven't used JBehave, IIRC the
jbehave.rb[1]<
https://issues.apache.org/jira/secure/attachment/12376069/
jbehave.rb>from
John Layton just searches for *
Behaviour.class, compiled from src/test/java

[1] https://issues.apache.org/jira/browse/BUILDR-49

--
vic

Quaerendo invenietis.