[rspec-users] Did I write my specs as I should?
guirec.corbel at gmail.com
Mon Nov 19 20:09:12 UTC 2012
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.
2012/11/18 Guirec Corbel <guirec.corbel at 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 :
> It's on my todo list. I'm not happy with my controllers specs. I think it's
> 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_bzh at hotmail.com> wrote:
>>> I read a lot about rails and BDD and I think I've found my own path. I
>>> 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;
>>> 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
>>> the database and do validation. All other things should have their own
>> 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 :
>>> 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 :
>>> but I just must moved my request in a feature folder. I don't want to
>>> request tests. I think it test the same thing
>> I'd recommend you read
>> 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
>>> 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"
>>> page.should have_content("Your project was created")
>>> 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"
>>> context "with invalid data" do
>>> it "render new template"
>>> 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.
>> Thanks and bye!
>>> rspec-users mailing list
>>> rspec-users at rubyforge.org
>> rspec-users mailing list
>> rspec-users at rubyforge.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rspec-users