Please, can you have a look on my controller's specs? It will be very useful for me. If you want, you can see other specs too.
Many thanks! 2012/11/18 Guirec Corbel <guirec.cor...@gmail.com> > You can show one of my project here : https://github.com/GCorbel/** > comment-my-projects <https://github.com/GCorbel/comment-my-projects>. In > this project, I should change the requests directory for features > directory. May be I also should follow this style : > https://github.com/jnicklas/**capybara#using-capybara-with-**rspec<https://github.com/jnicklas/capybara#using-capybara-with-rspec>. > It's on my todo list. I'm not happy with my controllers specs. I think it's > unreadable. > > My feature's specs are only for developpers. I prefere to write some > scenarios on a paper on with word and translate into code with capybara. I > find to use cucumber is a waste of time. > > I'm realy not sure with my controller's specs. It's not very useful for > design. It's just useful for code coverage. What do you think about that? > > Thanks for all David. > > Le 2012-11-18 09:02, David Chelimsky a écrit : > > 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<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<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/<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<http://rubyforge.org/mailman/listinfo/rspec-users> >>> >> ______________________________**_________________ >> rspec-users mailing list >> rspec-users@rubyforge.org >> http://rubyforge.org/mailman/**listinfo/rspec-users<http://rubyforge.org/mailman/listinfo/rspec-users> >> > >
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
