On Sat, Nov 17, 2012 at 3:51 PM, dougui <dougui_...@hotmail.com> wrote: > Hello, > > I read a lot about rails and BDD and I think I've found my own path. I want > to share my method and to know what you think about that. > > This is my workflow : > > Creation of feature specs (example 1); > > Only the happy path > Test only things than the user can view;
^^ This is a good guideline if you're not sharing these w/ non-tech business folk. If you are, however, there are going to be cases they'll want specified so you'll need to decide whether you want to share the whole rspec suite or just those in the features directory. > Don't test the number of records of the database, if an email is sent or > other things like that; > Keep it very simple; ^^ This can mean a lot of different things. I'd phrase this "keep things very high level". > > Watch the feature specs fails; > Create views and routes; ^^ This depends on _how_ the feature fails. What you do next is completely dependent upon the failure message you get. What I often find is that the first failure says "no route .." so I add a route. The next failure is "no controller action ..." so I add an empty controller action. Next is there's no view so I create an empty view template. Now we get a logical failure instead of an error, saying the content couldn't be found. At this point I'll start driving things out in controller specs and view specs as necessary. If there is no conditional logic in either place, I might bypass those (controller/view specs) for the moment, but as soon as a new scenario appears that forces any conditional logic into the controller or view, they get their own specs. > Watch the feature specs fail again; > Create the controllers specs (example 2); If you're just outlining them with pending examples (i.e. no bodies) that's fine. > Write the specs in complete isolation; > Use Factory Girl's build_stubbed; > Write a context for all conditons in ifs; > > Create the code for the controllers specs; Not all at once. They idea is to implement one example, watch it fail, then implement the code to make it pass, then on to the next example. > Create the specs for all model's methods I stubbed; > Write the code to pass the model's specs; > Refactor; > Continue to the next feature; > > I try to respect the single responsability principle (SRP) and Keep It > Simple, Stupid (KISS). > > With the SRP, the controller should manage the majority of objects and it > should not be a lot of depth. The models are used only for an interface with > the database and do validation. All other things should have their own > classes. This is an implementation decision which is neither correct, nor incorrect in the context of BDD. > I write specs for mailers, helpers and all other classes. > > I found this mail : > http://www.mail-archive.com/rspec-users@rubyforge.org/msg03883.html. And I > think it's similar. > > I don't like Cucumber and I prefer Capybara. You're comparing too different kinds of things. Cucumber supports a language (Gherkin) for expressing requirements at a high level and then binding those expressions to executable code. Capybara supports interaction with a browser (real or simulated). You can't replace Cucumber's role with Capybara. You can choose to bypass Cucumber/Gherkin if you like, but if you're not replacing it with high level language for expressing requirements, you're not doing BDD as it is described by it's thought leaders (mostly Liz Keogh - http://lunivore.com/liz-keogh) today. This is not to suggest that what you're doing something has no value. It's just not BDD. > > I read this : > http://alindeman.github.com/2012/11/11/rspec-rails-and-capybara-2.0-what-you-need-to-know.html > but I just must moved my request in a feature folder. I don't want to create > request tests. I think it test the same thing I'd recommend you read http://blog.plataformatec.com.br/2012/06/improving-the-integration-between-capybara-and-rspec/, in which José Valim explains the different kinds of things he thinks should go in feature specs and what he calls "api specs" (which spec request object internals like headers and response codes). > than my feature specs and it > will be slow to create two integration tests. > > Example 1 : A Request Spec > > describe 'Create' do > it 'add a new project' do > sign_in > visit new_project_path > within('#new_project') do > fill_in("Title", with: "My Project") > fill_in("Url", with: "http://www.google.com";) > select("Ruby", from: "Type") > click_button "Create" > end > page.should have_content("Your project was created") > end > end > > > Example 2 : A Controller Spec > > describe "#create" do > context "with valid data" do > it "redirect to project's path" > it "save the project" > it "set a flash message" > end > context "with invalid data" do > it "render new template" > end > end > > What do you think about that? Did I write my specs as I should? You're definitely on a good path, but it's difficult to judge by looking at only an incomplete outcome. The answer to that question lies in your own experience. Did the process help you clarify the requirements and design for yourself? Do the existing specs give you confidence that the code works properly? If you decided to support oauth, how many specs would need to change? If you decided to move from a sql database to a json api, how much of your spec suite would have to change? Etc, etc. HTH, David > > Thanks and bye! > > > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
