[rspec-users] Spec'ing via features

Andrew Premdas apremdas at gmail.com
Mon Nov 24 22:22:27 EST 2008

I came across this idea of dropping unit tests for acceptance tests in
the java world. It didn't like it there and I don't like it here, but
maybe thats because I'm an old fuddy duddy or something :). I do think
that every public method of an object should be specifically unit
tested, and yes that means that if you refactor your object you should
refactor your unit tests. This isn't really that much of a burden if
you design your objects to have simple and minimal public api's in the
first place.

What is that makes you think you can refactor code run acceptance
tests and be save without unit tests? Writing tests "that guarantee
the correct functioning of the system" isn't something you can just
do. Best you can hope for with acceptance tests is that part of the
system functions correctly most of the time in some circumstances.

Perhaps its the BDD ideal that your only writing the code you need to
make your acceptance tests pass, that make you think your acceptance
tests cover all your code. However just because you've written minimal
code to make an acceptance test pass doesn't mean that you can't use
this code in a multitude of different ways

Do you really think that BDD created code is just some black box that
you can tinker around with restructure and still be sure it works just
because your black box tests still work?

I just don't believe you can get the coverage you need for an
application using acceptance testing / features alone. If you do
actually write enough features to do this you'll end up doing much
more work than writing unit tests combined with features.

All best


2008/11/25 Raimond Garcia <lists at ruby-forum.com>:
>> Wow, if that's it in a nutshell... :)
>> Pat
> Thanks Pat, great summary.
> I have to admit that I'm as crazy as Yehuda,
> and believe that all we need are just acceptance tests,
> at different layers of abstraction, for clients and developers.
> I also see the benefits of speccing out single object's behaviors, with
> the aim of a good design.
> However, the drawbacks of doing this out-weight the benefits, in my
> opinion.
> Testing how every method of an object is going to behave,
> implies that after refactoring, that spec will no longer be useful,
> eventhough the business and application logic stay the same.
> I believe that being able to come up with a good design,
> is not only dependent on writing tests before your implementation,
> but also on knowing how to write a good implementation.
> This can be gained through experience,
> reading books, blogs, pair-programming,
> using tools to tell you about the complexity of your code,
> and a constant process of refactoring as we complete requirements,
> and then fully understand what the best design could be.
> Therefore in my opinion, by writing tests that guarantee
> the correct functioning of the system, we have a robust suite of tests.
> Let the refactoring come storming in and change the whole
> implementation,
> but the tests should not be affected at all,
> as I'm not testing my implementation nor design,
> only the correct functioning of the system,
> and relying on other tools on top of tests to maintain my code
> nice, clean and understandable by anyone that comes along.
> Kind Regards,
> Rai
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list