Or, conversely, autotest is awesome if you take the time to learn how to
use it:http://blog.davidchelimsky.net/2008/3/5/limiting-scope-of-autotest
Well, I find it easier to simply type:
$ rake spec
Then depending on what failed I will from time to time run a single spec
file:
$ spec spec/models/whatever.rb
On Tue, Mar 31, 2009 at 4:39 AM, Fernando P. [email protected]
wrote:
will make other calls to other models and do some fancy stuff, this used
without a 500 error. I don’t care if the view has such div except if it
distracting. From time to time I run specs to check if things look good,
- I don’t do true BDD, i.e: I still write code before specs, because
that’s what motivates me. I consider that seeing my app living and
writing code for my app more important than writing specs. Specs are
still important, but only as a bug reporting tool, they don’t add any
value for the customer.
Please be careful when making absolute statements like this. First of
all, even “just a bug reporting tool” adds tremendous value for the
customer, because your catching bugs before they make it to
production.
Secondly, the value to your customer of writing specs before code
depends on your personal skill level as it relates to writing them.
Spec-first adds considerable value for my customers because I know how
to move quickly through the red/green/refactor cycle, and it does
impact design, and therefore the quality of my code, and therefore the
short and long term maintenance costs. But, admittedly, I’ve been on
the TDD train ever since I learned about it back in 2003 and I kinda
know what I’m doing.
In this crisis If I wanted an employee to resign
by himself without paying him benefits (that’s how it works in Europe),
I would make him write specs all day long, and forbid him from seeing
the app and play with it. He wouldn’t last 1 week doing this.
Nor would anybody. From what you’re writing, it sounds like your
perception is that you write a bunch of specs with no code, and then
write code to pass the specs.
The point of TDD is writing small examples and small bits of code in a
cycle. The point of BDD is to write high level scenarios so you know
what code to write, but then drive it out in detail with TDD. My
personal experience is that writing this way is a lot of fun, filled
with small successes every few minutes. Admittedly, it’s not always as
fun as hacking together a quick prototype and seeing it come to life.
But the fun of that approach dies very quickly if the prototype
becomes the actual app and I find myself back-filling specs.
Hope that helps clarify.
Cheers,
David
aidy lewis wrote:
What editor are you then proposing? Or are you saying that all current
editors lag behind XP practices?
On Tue, Mar 31, 2009 at 5:39 AM, Fernando P. [email protected]
wrote:
will make other calls to other models and do some fancy stuff, this used
to happen in the controller which was bad. Now it has become so easy to
write model specs.
Great! Keeping controllers simple makes life better on many fronts.
- I don’t spec controllers, because it’s too painful to do. I don’t spec
views either, because I tweak them too often, and it would take me more
time rewriting view specs then actually coding the views. If there is
something to test for is the rendering of the css across browsers,
because that’s terrible!
I usually let Cucumber run through the basics of the action, but I
write controller specs for interesting thing that affect the behaviour
of an action such as requiring logic, or a certain permission, or
special error handling logic, etc. Pulling these things out into a
controller macro makes re-using them extremely simple. The next beta
release for The RSpec Book will cover doing that.
I write view specs because they change so much. I don’t spec the
structure of the page, just the semantics of it as it pertains to
information I programmatically display or don’t display. IME, when
apps are small there is a feeling that Cucumber can do it all, but as
the app grows Cucumber can be a burden as well. Cucumber scenarios
can’t do it all, and when you have interesting apps, hundreds of
scenarios and hundreds of steps it becomes way too time consuming to
try to find exactly what and why things died and why. I prefer focused
view specs for this regression rather than simply relying on Cucumber.
Also cucumber step definitions can become large and unwieldy. I like
focused steps which do enough to prove a scenario works as expected
and I like to drop down to specs for the details of it.
- I use cucumber+webrat to test that some important public pages render
without a 500 error. I don’t care if the view has such div except if it
is a critical one. What I mean is that I won’t test, all the assignments
that should be on the page, as some tutorials demonstrate. This is
nearly impossible to maintain.
I disagree with the last two sentences here. I build my views spec
first with examples that expect the result of “project.name” to be on
the page. Only then do I actually add it to the view. I have had no
issue maintaining this. Not only do I get a design benefit when its
not just a simple model attribute, but perhaps a calculated field, I
also get regression for free. I move swiftly, happily, and confidently
on without worrying about manually verifying everything on the page is
as it should be, I let my specs do that.
- I can refactor my code, immediately spot areas where my code got
broken, and fix it. Before some parts of my app would be broken without
having me knowing about it for a long time until some cool customers
report a few bugs, but this was not an acceptable situation.
IMO, this is the case when people don’t write view specs. Unless
someone’s Cucumber scenario covers everything on the view (which they
don’t unless its a super simple CRUD app). Half the time I wonder if
people even know if their views are displaying the write things on the
page over time. How would they not know w/o specs? Do they manually
verify every page every time they deploy? That seems impossible to
maintain.
- I don’t use Autotest, it sucks too much power, and it is too much
distracting. From time to time I run specs to check if things look good,
and always before updating the code on the server.
Agreed. I loathe autotest, but I don’t run specs time to time, I run
my specs all the time. It’s a part of my development process. Red
Green Refactor. It’s not just a mantra, its a discipline. Although
when I don’t know what I want or need to do, I spike something
(without any tests), and once I figure it out I scrape the spike (or
comment it out) and drive it with examples.
- I have written my own Factory. It’s not OOP, it could be refactored,
but it works 100% as advertised, provides default values, can handle
associations, etc. I am pleased with it (I tried factory girl,
machinist, etc and got pissed off). I encourage anyone to write his own
little factory, to get a better hang of how to write good specs. I
totally got mad with fixtures, it is impossible to maintain specs/tests
with fixtures. Impossible.
Cool. Is it on github? I wrote my own as well, but then switched to
FactoryGirl because everyone I talked to loved it, but now I wonder if
they really loved it (or how much they actually use it) because it
works for about 80% of the things I need, and fails horribly for the
other 20%. I want to try Machinist next, but I’m sad to see you had
bad experiences with it. 
And I hate the idea behind ObjectDaddy, adding methods to the model to
generate spec data. Gross.
You’ve probably seen this, but it never gets old, “Testing is for
testers.” When you focus on specs solely for the benefit of testing
then you are only getting the tip of the ice berg. Traditional “tests”
are really they to provide safeguard against regression. This is a
secondary benefit to BDD. BDD is about driving your app from the
outside in, focusing on the behaviour at different levels.
For example, Cucumber lets you focus on the app behaviour, while view
specs lets you focus on the expected behaviour of a view (to display
“project.name”), and controller specs let you focus on the behaviour
of a controller (such that only “admins” can destroy a project), and
model specs let you provide examples for how it should be working.
Focusing on the behaviour at these different levels forces you to
write better designed code, more focused objects, simpler controllers,
just-the-right size models, etc.
A better design lets you move fluidly through the app as it evolves
and changes. When you use BDD, you get a better design as a part of
the process. As a nice secondary benefit you get protection against
unwanted regression.
I encourage you and anyone else to practice your BDD more. The more I
practice the more fluently I can drive my app with examples form the
outside-in, and the more capable I am to know when to write a
controller spec and when not to—and it’s not based on if it takes
too long. The decision is based on experience for knowing how-to do
it, and how-to do it well, and then asking myself, “Does this get me
anything?”
Not spe’cing something because you don’t know how-to spec it well is
most likely not an issue with BDD. It’s a skill deficiency with the
developer. The only way to make good decisions it practice and become
more familiar with your tools. Then you will start making informed
decisions that add value to your project. The alternative is that you
make uninformed decisions and you or other developers will suffer down
the road because you made a bad decision but didn’t know it because
you lacked the knowledge and/or experience to know it was a bad
decision.
Best regards,
Posted via http://www.ruby-forum.com/.
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
–
Zach D.
http://www.continuousthinking.com
On Tue, Mar 31, 2009 at 1:10 PM, Zach D. [email protected]
wrote:
typically does only 1 call to a model and behind the scenes that model
something to test for is the rendering of the css across browsers,
structure of the page, just the semantics of it as it pertains toissue maintaining this. Not only do I get a design benefit when its
distracting. From time to time I run specs to check if things look good,
- I have written my own Factory. It’s not OOP, it could be refactored,
works for about 80% of the things I need, and fails horribly for the
value for the customer. In this crisis If I wanted an employee to resign
are really they to provide safeguard against regression. This is a
just-the-right size models, etc.
too long. The decision is based on experience for knowing how-to do
you lacked the knowledge and/or experience to know it was a bad
decision.
This isn’t intended at you Fernando. This is just “in general” my
thoughts, all of which have come from my own journey, as well as many
discussions on-line and off-line.
–
Zach D.
http://www.continuousthinking.com
http://www.mutuallyhuman.com
–
Zach D.
http://www.continuousthinking.com
David C. wrote:
Or, conversely, autotest is awesome if you take the time to learn how to use it:
http://blog.davidchelimsky.net/2008/3/5/limiting-scope-of-autotest
Even with -f, after it ran our most recently changed test…
…it started the grand wazoo test batch.
Pass! I can just use autotask or the truly stupid trigger.rb script I
drag
around to TDD. They would just defer to test:recent. We have our suites
and
files all cut up into bite-sized chunks for a reason…
On Tue, Mar 31, 2009 at 2:19 PM, Fernando P. [email protected]
wrote:
Please be careful when making absolute statements like this. First of
all, even “just a bug reporting tool” adds tremendous value for the
customer, because your catching bugs before they make it to
production.
Value is what a customer is something he is ready to pay more money for.
Well, we could argue that specing/testing can improve my workflow and
get new features added or improved faster… A Ferrari could also get me
to work quicker
If (if!!!) writing specs first makes you go faster, then you’re
faster for free. The Ferrari bears a bit of a different cost/benefit
ratio 
Cheers,
David
Please be careful when making absolute statements like this. First of
all, even “just a bug reporting tool” adds tremendous value for the
customer, because your catching bugs before they make it to
production.
Value is what a customer is something he is ready to pay more money for.
Well, we could argue that specing/testing can improve my workflow and
get new features added or improved faster… A Ferrari could also get me
to work quicker
On 31 Mar 2009, at 18:19, David C. wrote:
Autotest sucks. If we have too many tests, it runs them all, and
this slows
us down.Or, conversely, autotest is awesome if you take the time to learn
how to use it:http://blog.davidchelimsky.net/2008/3/5/limiting-scope-of-autotest
Thank you.
Matt W.
http://blog.mattwynne.net
On Wed, Apr 1, 2009 at 8:01 AM, aidy lewis [email protected]
wrote:
that as a software tester I would in combination with a customer
create the feature Acceptance Criteria (AC). The AC would be used by
the developer to guide his\her design, but he\she would be unlikely to
implement the automated test, which would normally be done by the
tester (using Watir\Cucumber). My feeling is that if we are to get the
optimal benefit from TDD\BDD then the developer(s) should be
automating the AC. What do you think?
Given that I don’t know the skill-set available on your team, it’s
difficult for me to say what would provide optimum benefit for your
team. That said, in some idealistic BDD fashion, I’d think the best
deal would be the tester and developer pairing on automating AC. Then
that developer would pair with another developer driving out the code
w/ TDD.
I don’t think this removes the need of the tester as he/she may be
more likely to have a skill-set that is aware of
bigger-than-unit-test-tools and frameworks, but I think they should be
pairing with the developer.
I honestly wrote the above before I read this Yes, I agree, tester
and developer pairing is generally a good thing.
However the problem then arises if the
developer and tester use different languages. I use Ruby while the
production code is in .Net. The TDD interplay would be more seamless I
think with a single language. But as a tester it would be insane for
me to use a static and compiled language to - in effect - test a web
site.
I’m going to go out on a limb here and suggest that if you’re
proficient in Ruby and you’re pairing with a reasonably skilled
developer in any C-based language like C Sharp, the language barrier
will be fairly small. There are some hoops, like meta-programming,
blocks and iterators, but not too many beyond that. I don’t mean that
to be flippant. Even if the dev has zero experience with these
concepts, he really doesn’t need to understand them in order to
progress if you’re pairing.
HTH,
David
Hi David
2009/4/1 David C. [email protected]:
. That said, in some idealistic BDD fashion, I’d think the best
deal would be the tester and developer pairing on automating AC. Then
that developer would pair with another developer driving out the code
w/ TDD.
If we have two different sets of people implementing the AC and
driving code with TDD then does this not prevent the TDD\BDD
interplay? Development is in small steps, so if we create a mock for
the first AC step see it fail then move down into TDD to make that
pass, refactor then move up (red => green => refactor) again - then
this - to me -, has surely got to be done by the same set off people.
I think the user step mocks are likely to be re-factored out when we
have some tangible output (e.g a GUI)
I’m going to go out on a limb here and suggest that if you’re
proficient in Ruby and you’re pairing with a reasonably skilled
developer in any C-based language like C Sharp, the language barrier
will be fairly small. There are some hoops, like meta-programming,
blocks and iterators, but not too many beyond that. I don’t mean that
to be flippant. Even if the dev has zero experience with these
concepts, he really doesn’t need to understand them in order to
progress if you’re pairing.
When you go to Harversters they ask ‘have you been here before?’.
Maybe not, but I can eat with a knife and fork.
However, - I will put myself on a limb - some programmers have been
conditioned by MS on the practices and uses of tools. No intellisense,
no visual debugger, no static assignment or compilation, a command
line!*@? Many are just not happy with it.
Aidy
Hi David
2009/3/31 David C. [email protected]:
The point of TDD is writing small examples and small bits of code in a
cycle. The point of BDD is to write high level scenarios so you know
what code to write, but then drive it out in detail with TDD.
Does this necessitate that the same person or pair should be doing
both the TDD and BDD for the same area? My problem at the moment is
that as a software tester I would in combination with a customer
create the feature Acceptance Criteria (AC). The AC would be used by
the developer to guide his\her design, but he\she would be unlikely to
implement the automated test, which would normally be done by the
tester (using Watir\Cucumber). My feeling is that if we are to get the
optimal benefit from TDD\BDD then the developer(s) should be
automating the AC. What do you think?
I don’t think this removes the need of the tester as he/she may be
more likely to have a skill-set that is aware of
bigger-than-unit-test-tools and frameworks, but I think they should be
pairing with the developer. However the problem then arises if the
developer and tester use different languages. I use Ruby while the
production code is in .Net. The TDD interplay would be more seamless I
think with a single language. But as a tester it would be insane for
me to use a static and compiled language to - in effect - test a web
site.
Aidy
6 months since my initial post, what happened in between?
Damn! BDD + writing specs that don’t hit the database, also taught me to
not break Demeter’s law 
It’s simply a huge pain to spec a double dot method call, i.e:
user.membership.paid?
ActiveRecord associations are super, but they can back fire pretty bad
if you abuse them.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs
