buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Riou" <matth...@offthelip.org>
Subject Re: Where do we put specs: src/test or src/spec?
Date Fri, 22 Feb 2008 20:01:02 GMT
On Fri, Feb 22, 2008 at 11:33 AM, Assaf Arkin <arkin@intalio.com> wrote:

> 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.
>

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?


>
> 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 <arkin@intalio.com>
> > 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 <
> vic.borja@gmail.com
> >>>>
> >>> 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.
> >>>>
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message