I'm just learning Cucumber and BDD way to create applications.
When I'm start learning rails by http://guides.rubyonrails.org/ I'm use scaffolding to generate CRUD functionality and skeleton to my controllers and views. This way give me large speed up versus PHP custom writing code. But when I'm looking to cucumber screencasts, reading comments about BDD, or looking to https://github.com/diaspora/diaspora source code - all of them doesn't use scaffold. When I try to write tests I'm spent long time to compose and test, but I know that the basic code which generated by scaffold isn't crashable. That is my question: How give compromise between BDD and scaffold speed?
The scaffold serves as a good starting point whilst you are getting to know the TDD/BDD cycle. I found that when I first read the RSpec Book that it was confusing with what to use when and why ! Then along came the Cucumber Book which helps a little more since it takes you through the steps a little slower (although the book is still in beta, but a fantastic resource).
One other great resource that helped was a blog post by Sarah Mei called "Outside-in BDD: How?". What is nice about this post is the discussion of the flow and style that you use as a developer. This was useful since it puts some context around the style of doing BDD and not just a re-hash of a basic example.
Of course there is the usual debate that 'real programmers' shouldn't use the scaffold. That may be true for a large scale, production application. The reality is that we all have to learn and start somewhere and Rails is no exception; it's a large framework and once you add in RSpec + Cucumber the breadth and depth grows very fast.
Related
I find it not so easy as one might think to start with TDD in Rails.
I've searched for some examples but no-one really explains how to do TDD/BDD with Rspec AND cucumber. They usually use an old version of rspec, or prefer one on the other (so you find cucumber tests and rspec tests separated). And by the way the say what to do, but the real process is often not explained at all (I've read a lot on make them work togheter with Capybara, but only once on how to proceed on bdd with them).
I'd like to know how to use them togheter, how to avoid test duplication (disabling view specs and other tests that should be done with cucumber), and maybe an explanation of what not to test (for example I find it useless to test the HTML output in most cases, it can be useful to test if you're logging in to match what you're seeing, for example a flash message).
Can you please provide a step-by-step list of how do you proceed with BDD using this two tools togheter? It would be nice a fresh tutorial (using latest versions) or maybe a screencast.
Thanks.
I highly recommend you the Rspec book which is exactly what you are looking for :
It explains how to use Rspec and Cucumber together with a simple 2 loops process : The outer big loop is a Test - Code - Refactor process you do with cucumber and each step is made of multiple iteration of a Test - Code - Refactor process you do with Rspec.
That books explains at the same time how and when to use each of the two tools.
If you want a broader vision of TDD-BDD, I also suggest you the GOOS book which is more language/tool agnostic and more process oriented.
My software company never did BDD or even TDD before. Testing before meant to simply try out the new software some days before deployment.
Our recent project is about 70% done. We also use it as a playground for new technologies, tools and ways of developement. My boss wanted that I switch to it to "test testing".
I tried out Selenium 2 and RSpec. Both are promising, but how to catch up months of developement? Further problems are:
new language
never wrote a line of code by myself
huge parts are written by freelancer
lots of fancy hacking
no documentation at all besides some source comments and flow charts
All I was able to was to do was to cover a whole process with Selenium. This appeared to be quite painfully (but still possible), since the software was obivously never meant to be testet this way. We have lots of dynamically generated id ´s, fancy jQuery and much more. Dont even know how to get started with RSpec.
So, is it still possible to apply BDD to this project? Or should I run far away and never come back?
Before you start - have you asked your boss what he values from the testing? I'd clarify this with your boss first. The main benefits of system-level BDD are in the conversations with business stakeholders before the code is written. You won't be able to get this if all you're doing is wrapping existing code. At a unit level, the main benefits are in questioning the responsibilities of classes and their behavior, which, again, you won't be able to get. It might be useful for helping you understand the value of the application and each level of code, though.
If your boss just wants to try out BDD or TDD it may be simpler to start a new project, or even grab an existing project from someone else to wrap some tests around. If he genuinely wants to experiment with BDD over legacy code, then it may be worth persisting with what you have - #Esko's book suggestion rocks. Putting higher-level system tests around the existing functionality can help you to avoid breaking things when you refactor the lower-level code (and you will need to do so, if you want to put tests in place). I additionally recommend Martin Fowler's "Refactoring".
RSpec is best suited to applying BDD at a unit level, as a variant of TDD. If you're looking to wrap automated tests around your whole environment, take a look at Cucumber. It makes reusing steps a lot simpler. You can then call Selenium directly from your steps.
I put together a page of links on BDD here, which I hope will help newcomers to understand it better. Best of luck.
Reading the book Working Effectively with Legacy Code might be helpful. There is also a short version in PDF form.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
As a long time php dev and a rails newb I've been trying to get a grasp on tdd/bdd. There are so many tools and methodologies out there that this can be a pretty daunting task. After a lot of reading I came to the conclusion that this would be my preferred method of testing:
No cucumber, it seems to me that it's just an unnecessary complexity.
RSpec for unit tests
RSpec/Capybara for integration/acceptance tests.
No testing for controllers/views.
Factory Girl or Machinist for factories.
Don't mock my own code.
Being a total BDD newb, this could be way off base so feel free to offer suggestions on this testing 'stack'.
What I'm really looking for though is an open source project using these tools that I can look to for inspiration.
Tutorials would be appreciated too, but I think seeing a real world project implement all these ideas would be very helpful.
Everyone seems to have their own recipe for testing that works for them. My background is like yours -- long-time PHP developer using no tests (but doing plenty of manual white-box testing while developing). I recently started writing my first production-level, getting-paid-for-playing-with-Rails app. Here are my thoughts after the first three months.
I too found Cucumber to be too complex for me to start with. I struggled with it for far too long before finally realizing that I was just too far removed from the actual testing framework. Once I dropped down to pure RSpec things became much clearer. That said, now that I've written my first app with a robust test suite I think I could probably drop Cucumber into my next Rails app recipe and feel more comfortable using it for integration testing while still using RSpec for unit testing.
I've developed an unhealthy infatuation with RSpec once I finally understood the process. It really is beautiful to run those tests and see all green. Actually, it's even satisfying to see red because it tells me what to work on next.
I'm using the default Webrat for integration tests. I haven't run up against anything that Webrat couldn't solve, but I haven't given Capybara a try either so maybe I just don't know how bad I have it.
I started writing my tests by following along with the Rails Tutorial Book, and in it the author says "Since I’m not partial to separate tests for views or helpers, which I’ve found to be either brittle or redundant, our first step is to remove them." (Page 93, paragraph 2) After writing a bunch of helper methods, I decided to go back and write separate helper tests for all of them. I'm still rolling my view tests into my controller tests, but I could see separating them in my next project. FWIW, I think you really should be writing tests for everything at some level, even if you're just relying on your controller tests to exercise your views, and/or your view tests to exercise your helper methods.
I'm using Factory Girl with this project and I have found it to be very useful and easy to use. I haven't tried Machinist but it seems to be equally popular. One thing I will mention is that when I first started writing my factories I also used the FFaker gem to generate random content into every factory object that I created. This seemed nice at first as the variable content sometimes caused me to find things that I had missed in development (can't think of a good example at the moment, though), but it also meant I had to worry about truncating all of the returned FFaker data to fit wihtin the length constraints in the model. This proved to be too unwieldy in the long run so I removed all of that code and went with using static strings for all my factories, and only for the required fields. Then when I wanted to exercise a specific field I would do so in my actual specs. IMO, your factories should contain only enough data to create a valid object and no more.
As for mocking, I've only found a few places where I needed to mock something, but perhaps I'm too new to Rspec to know that I'm doing it wrong.
And finally, as for specific examples, just look on GitHub for example Rails apps or open source Rails projects that contain tests. Or follow along with the Rails Tutorial Book as I did. Whatever you decide to do, start as close to the metal as possible and then try different gems/plugins/etc, always making sure you can back off your changes if you decide you don't like the results. I found that trying to start with a complete recipe (i.e. suspenders, blue-light-special, etc.) was too overwhelming. By starting with a raw Rails app I was able to try out different solutions (paperclip versus carrierwave, typus versus rails_admin, clearance versus devise, etc.) to see which ones worked for my personal preferences. It's clear that there is no one perfect recipe for a Rails app, and everyone's preferred recipe is just an opinion.
I've got analysis paralysis looking at all the different functional testing options for a new grails (v1.3.4) application. I've looked at
WebDriver/Selenium (which I've used before)
WebTest/Canoo
Geb
Tellurium
Grails Functional Test
and there must be others. I think some of the criteria that I would use to make a decision include (in no particular order):
Likely longevity, active development
Can do ajax/javascript
Support for PageObject or similar patterns
Maturity
Headless (eg htmlunit) is ok, especially if it makes things go faster
Good reporting
Support for NTLM credential provider or similar
Compact, robust test scripts
Takes advantage of groovy language
I would be particularly interested to hear from people who have tried more than one framework. Thanks!
I maintain the plugin for WebTest but I'd recommend giving Geb a try. I haven't used it personally on a project yet but I think it will tick off most of your criteria.
It is the most actively developed (IMO) but is quite new. It is built on WebDriver/Selenium so should also be a good fit with your past experience.
WebTest doesn't see a lot of development these days and does not have built in support for page objects. But it does give you great reports. It's downside is it's historical foundation of Ant. It makes it hard to test in a dynamic fashion as your test steps are built up when the test case is executed and then the actual test is run as a second pass.
I have used GFunc as well but the lack of reporting is a real pain and it does not get as much development as Geb. It is far more "groovy" than WebTest though and is a thin wrapper over HtmlUnit allowing you to "roll your own" testing functionality quite easily.
cheers
Lee
Grails Functional Test is HtmlUnit only. I wouldn't suggest coding directly to HtmlUnit these days with the other frameworks that are available that give you page object and better abstraction out of the box.
I've used the webdriver plugin which seems to work pretty well and has page object built in - but the page object support is coupled to the JUnit hierarchy, which makes it hard for me to use because I want to also use Cucumber.
I'm very excited about Geb and am hearing a lot of success stories with it but haven't gotten to finish setting it up myself.
Currently, I have a project, where I have to add some features on to it, but the coding hasn't maintained any standards and it is extremely tough to break it down into manageable and understandable parts, to get started. And there is no documentation, to help out?
How would you start such project, if you had to?
Steps:
(Optional) Cover system with hi-level automatic tests, which test system through UI example
Carefully refactor to testable code
Cover functionality with unit tests
Refactor code to make implementation of new features possible
Implement new features
Manuals:
Book by Michael Feathers: Working Effectively With Legacy Code
Book by Martin Fowler: Refactoring