On Tue, Mar 31, 2009 at 1:10 PM, Zach Dennis <zach.den...@gmail.com> wrote: > On Tue, Mar 31, 2009 at 5:39 AM, Fernando Perez <li...@ruby-forum.com> wrote: >> Fernando Perez wrote: >>> Hi, >>> >>> Today is a big day. I officially transitioned from manually testing by >>> clicking around in my app, to automated testing with RSpec + Autotest. >> >> 6 months since my initial post, what happened in between? >> >> - My controllers are getting anorexic, and that's good. An action >> typically does only 1 call to a model and behind the scenes that model >> 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. > >> - 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. 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. >> >> What about you? >> > > 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.
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. > > >> >> Best regards, >> -- >> Posted via http://www.ruby-forum.com/. >> _______________________________________________ >> rspec-users mailing list >> rspec-users@rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > > > > -- > Zach Dennis > http://www.continuousthinking.com > http://www.mutuallyhuman.com > -- Zach Dennis http://www.continuousthinking.com http://www.mutuallyhuman.com _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
