We have chosen to use rails to build a small project of ours. This is a really small project and will likely take six man-months or less. All people working on the project are new to Rails and have limited amount of experience in web coding.
Our software is supposed to give users an easy-to-use interface to browse vast quantities of measurement data and visualization. Users identify themselves using a user account which limits which data they can see.
What sort of automated tests should we do and are there any freely available tutorials that would help us in this?
Consider the three "legs" of the MVC (model-view-controller) design pattern on which Rails is based.
Views
These should be largely devoid of business logic: code should be concerned with display of data and manipulation of the UI only.
Controllers
Minimal logic (conventional wisdom is to work with "thin controllers"). Testing (in the 'test/functional' directory) should be straightforward and - hopefully - mostly concerned with navigation and response content verification. Start with the idea of keeping these as simple as possible for as long as possible, so you'll be ready for the more complex testing topics when they're needed.
Models
This is where the business/domain logic lives. Keeping it in models makes it easier to test, which is good because you should be writing most of your tests against the models, particularly in the earliest period of development. Using tests to define behaviour before it's implemented has the added benefit of steering your code towards a cleaner, decoupled design, so try to do that as much as possible.
It's probably worth looking at Noel Rappin's Rails Prescriptions - there's a book and a (free) introductory PDF that covers Rails-specific test issues in some detail.
For all things rails, there are railscasts. Here's a a good one on testing with rspec: Link! (browse around to find more good stuff), and I could not recommend autotest more highly. After that, there is a lot of things you can do, depending on the test you want to write. (selenium, fixtures)
Unit testing is great and all but I think it's worth at least checking out blackbox testing
You might also want to get the book Agile Web Development with Rails. There is a chapter on using the rails testing system.
For higher level tests, you can look at Watir or Fitnesse or Selenium.
Thoughtbot's Shoulda is a very easy to use and intuitive testing framework, with natual language options and not much "magic" that has to be learned through tutorials and api reading.
Dave Thomas, one of the authors of the fantastic Rails book Agile Web Development with Rails offers a good, quick overview of Shoulda.
Related
I would like to write some automatic tests for my Rails 3 application.
I wonder how to start with that.
I've heard about Selenium/RSpec/Cucumber, and I guess there are many more options.
What are the advantages/disadvantages of these testing frameworks ? Which of them has the best documentation ? Which one is the most popular in the Ruby world ? And in the industry at all ?
I have the general knowledge of how to write tests. I just want to learn the appropriate testing framework(s) for testing Rails applications.
Please help me to decide with which testing framework to start.
There are many tools for testing rails and other webapps from many different aspects. But if you are new to testing I highly recommend you start with learning Rails own testing framework before start using other tools.
Learning, and later mastering, one testing framework makes it easier in the future to understand pros/cons with other framework and make them work in unison.
You could start with testing the following things:
Unit Testing your Models
Functional Tests for Your Controllers
Learning about Fixtures and how to load test data
I have seen many failed testing efforts, but I never saw them fail because they choose the wrong tool/framework. They fail because they don't know how to master the tools they use, and learn enough about the basics about testing.
Read more about Rails testing here.
http://guides.rubyonrails.org/testing.html
Manual Exploratory Testing
As much as I love automated testing it is, IMHO, not a substitute for manual testing. The main reason being that an automated can only do what it is told and only verify what it has been informed to view as pass/fail. A human can use it's intelligence to find faults and raise questions that appear while testing something else.
Read more about mixing Automated and Manual Testing in another of my answers here:
What test methods do you use for developing websites?
I wouldn't say there is any one best set of testing tools out there; and the community definitely has not decided on any being standard in any way.
I highly recommend The RSpec Book from the Pragmatic Programmers-- about half of the book is on testing with Rails with Cucumber, RSpec, and browser simulators like Selenium. It's a comprehensive overview of the different situations you will find yourself in with Rails and what tools you might want to use in each situation.
Selenium is a framework to automate testing of user interface. Selenium script launches a browser window, goes to a web-page and manipulates page elements.
RSpec and Cucumber are tools for what is called "behavior driven development (BDD)". BDD is a development process where you have description of a separate feature, and some script (can be a Selenium script) that checks this feature. RSpec and Cucumber basically connect these two, so that when you run a test script, you see the list of features written in plain language and their testing status.
Selenium scripts can be written in a number of languages, while Cucumber scripts use Ruby. Documentation is OK for all of them, some knowledge of programming language is required though.
Starting links:
Cucumber;
Selenium;
Testing rails applications
The easiest way to get started is using TestUnit. When you generate a model, view, controller using scaffolding it will automatically generate a testing folder for you containing a test environment setup file and tests, or you can add tests to existing models with a rails generator.
It is then a matter of reading the documentation on TestUnit, of which there is a fair amount.
For a next step, my personal preference is to use RSpec over Cucumber - I've found Cucumber hard to maintain, and whilst it is wonderful to have tests that are readable by your boss, I've found that most bosses don't really want to read or contribute to tests, and it makes for time-consuming development and is very 'bitty' - lots of small bits of text scattered in various files.
If you want to jump right in and begin using RSpec for Rails, then I'd recommend Rspec-Rails, which includes many helpers for asserting the correct behaviour of your application.
I could go on, but you've asked for 'where do I start' - there's two good places.
There are a bunch of frameworks that help you test your ruby/rails code... the great thing is the dynamic nature of Ruby gives you a lot of flexibility.
I like to use RSpec to test the internals of my code, and Cucumber to test the application's behavior. So generally, RSpec will test models and methods, and Cucumber tests user interaction through the browser.
I highly recommend this pragmatic programmers ebook on BDD using RSpec on Cucumber.
Railscast on getting started in cucumber (also called cukes)
Cucumber project
Rails project
I'm new to rails, and I read recently on the internet (so it must to be true) that the TDD library that comes with rails is incompatible with RSpec, but also I read that RSpec is the right tool to do test.
So, my question is, if this is truth, what is the right tool to make test with rails: the rails TDD or RSpec? Or are this 2 tools total different purposes?
Thank for the clarifications!!!
TDD means test driven development. It's a methodology, not a library.
Rails ships with Ruby's Test::Unit. It is easily replacable with other libraries such as Rspec, should you wish to do so.
There is no "right way" when it comes to which tool to use. It's all down to preference. I prefer Rspec personally...
RSpec is pure Ruby and a very good way to write tests for your code. It is easy to integrate using Gems and is straightforward to work with.
There are many tools for testing rails and other webapps from many different aspects. But if you are new to testing I highly recommend you start with learning Rails own testing framework before start using other tools.
Learning, and later mastering, one testing framework makes it easier in the future to understand pros/cons with other framework and make them work in unison.
You could start with testing the following things:
Unit Testing your Models
Functional Tests for Your Controllers
Learning about Fixtures and how to load test data
I have seen many failed testing efforts, but I never saw them fail because they choose the wrong tool/framework. They fail because they don't know how to master the tools they use, and learn enough about the basics about testing.
Read more about Rails testing here.
http://guides.rubyonrails.org/testing.html
Manual Exploratory Testing
As much as I love automated testing it is, IMHO, not a substitute for manual testing. The main reason being that an automated can only do what it is told and only verify what it has been informed to view as pass/fail. A human can use it's intelligence to find faults and raise questions that appear while testing something else.
Read more about mixing Automated and Manual Testing in another of my answers here:
What test methods do you use for developing websites?
I'd like to enable the business analysts to be able to write all of their specs for features, scenarios and steps that is Cucumber friendly using Gherkin.
I've read some of the basic info on the github site for Cucumber and from doing a quick Google search but wanted to know if there were recommended resources for getting non-technical folks to be able to write comprehensive BDD using Gherkin (I assume that's the preferred language for Cucumber tests to be created in).
Thanks.
What I did with the business analysts in our company was to teach them the structure by giving them the keywords: Given, When, Then, And for Scenarios and In order to, As a and I want to for Features.
Then I gave them a simple example and told them to write down their own features as they thought they should be written. Surprisingly enough the structure was self explanatory and the features they wrote became a great start.
The only big problem was that they had contained to much logic in each scenario step. I solved that by iteratively asking "why?" which in most cases revealed the core functionality they were after and we re-wrote the scenarios accordantly.
By giving them the guidelines and letting them write the features themselves they got their hands dirty and were forced to think about what they wrote. Today they have a much better understanding and the "why?" iterations are not that common anymore.
Ofcourse you need to have the business analysts and the developers to work closely together and the features the analysts write should only act as a start. Remember that the Cucumber features are just a common language between the analysts and the developers. They still need to sit together often to be able to speak with each other :)
http://cukes.info is a great resource for teaching people how to write them. Ben Mabey also made a great presentation on Cucumber at Mountain West Ruby Conference 2009.
Having just worked on an agile project using cucumber for the first time I think that the best way to learn Cucumber and Gherkin is to get your hands dirty.
I may be wrong but I get the impression from your question you are wanting to train your BAs to write Gherkin; then they will write a bunch of features and hand them to developers.
This is definitely not the way to go. It is much better to have BA's devs and users (if possible) working together to write your scenarios and build them as you go. Then you all learn together what works and what doesn't.
We tried having a BA write entire features and hand them over. We (the devs) ended up having to do major rewrites because the implementation ended up different to that originally envisioned by the BA. We also had to change the syntax of the steps and do find and replace through the whole file.
Do one scenario at a time, get it working then move on to the next. An iterative approach reduces wasted effort and makes sure you all understand how you want the app to behave.
In terms of how to write steps it is best to start with the ones that come with Cucumber and copy and adapt them as you work on your project to fit your particular application. There is no right or wrong, it is what works for you. The documentation on the cucumber sites is generally good and will be a valuable resource as you learn more.
We are teaching Gherkin (for SpecFlow) in a similar way, how mrD has described it.
I think it is very important though, that the audience is familiar with the main intention of "Specification by Example", agile requirement analysis and BDD, so we usually start discussing the background first. We also show a sample Gherkin scenario and explain the very basics (like Given/When/Then/But and tables).
Than we take a simple example story (that is quite familiar to everyone), like "add items to shopping cart" (with some orientation, of course) and let them formulate the acceptance criteria in small groups.
After that every team shows / explains their solutions and we discuss the good and bad practices that were present. After the second team, you can see almost all of the most important (good or bad) practices appearing.
I also type in the concluded solution, and show here alternative ways of describing the scenarios (background, scenario outline, etc.). If there is enough time, I also show how to automate & implement the imagined functionality based on that. This also help to understand some important rules to follow, that makes the automation much easier.
Although, I never know upfront what will happen, usually this exercise is the best part of our BDD training.
The RSpec book has a couple of chapters in it that are relevant to Business Analysts:
http://pragprog.com/book/achbd/the-rspec-book
I think the best way to learn is to start writing. Gherkin & Cucumber are easy to learn but difficult to master, so it’s important to get to practical examples as soon as possible.
While it’s important to get started by writing your first scenarios, you also need some resources to establish good habits and understand key practices. I wrote a book that could help. “Writing Great Specifications” is, I hope, a good way to learn Gherkin and Cucumber. It covers patterns and antipatterns as well as key techniques for writing great scenarios. :) If you have any questions, you can always hit me up on Twitter.
If you are interested in buying “Writing Great Specifications,” you can save 39% with the promo code 39nicieja2 :)
Other great resources:
“Specification by Example” by Gojko Adzic if you’re interested in software development processes and high-level engineering practices.
“BDD in Action” by John Smart if you don’t mind reading testing code in Java. It’s a comprehensive end-to-end view on defining and testing software requirements.
“Behaviour-Driven Development” by Liz Keogh if automated testing doesn’t ring a bell, but you want to understand how specifications with examples affect your business analysis processes.
“The Cucumber Book: Behaviour-Driven Development for Testers and Developers” by Matt Wynne and Aslak Hellesøy
“The RSpec Book: Behaviour-Driven Development with RSpec, Cucumber, and Friends” by David Chelimsky, Dave Astels, Zach Dennis, Aslak Hellesøy, Bryan Helmkamp, Dan North
Best way to learn Gherkin is to read the Behat documents first: http://behat.readthedocs.org
Then read official documents from cucumber site: https://cucumber.io/docs/reference
Also, you can read Guru99 article to write your first cucumber script: http://www.guru99.com/your-first-cucumber-script.html
I am (quite) an experienced programmer but totally new to Ruby and Ruby on Rails.
RoR looks great to get working quickly, specially the automatic screen generation for CRUD operations.
It really it gets you productive quickly.
The questions is with the last 20% of the work, when I must finish my application. Won't RoR conventions stand in my way? Because not every database table must be available for all users, and not all users can edit all columns and/or all rows, and the views must be adapted to my site's look and feel, etc.
I understand RoR has been used successfully in live sites, but how exactly do you gain enough speed in RoR to escape gravity after the first phase has been burned out.
I don't think scaffolding gets you 80% there. Scaffolding is nice in that it shows you how the pieces of Rails fit together, but I wouldn't build my application off of scaffolding code. Now that you've been impressed by scaffolding it's best that you forget all about it. :)
Where Rails really shines in my mind is database migrations, the awesomeness of how dynamic ActiveRecord is, and the plugin ecosystem.
There's a lot to learn when deciding to go with Rails. You have a new language, new framework, and new plugins - but if you take the time to learn those things you can be very productive with Rails.
I've been doing ruby on rails for quite sometime. The 80/20 problem is not unique for rails. It applies generally to the entire world. I'm also not aware of any framework that can just do business logic for you.
To answer your specific questions. Conventions will not stand in your way while doing the 20%. Instead, conventions will help you to get through that 20% quicker.
Personally, for user authentication, I use Authlogic. For user authorization, I use Lockdown or Authorization plugin depending on customer need.
I also use inherited_resource in most of my projects to simplify controller code. This is another power of convention.
To increase speed of development, you will not only need to know Rails, but rails gems/plugins that does the right things for you, so you don't have to reinvent the wheels again. Also, knowing Ruby language is a must for quickly develop beyond the 80%.
Ruby Toolbox provides some of the most popular gems and plugins used in typical rails projects targeted at specific domains. You can look through the relevant categories and know what most people use. (And it's probably a good idea to use popular, well maintained gems)
TDD/BDD style development will also help you to speed up in the long run.
Lastly, a warning: If you stray away from rails convention, you will have a painful time in general.
P.S. I used Merb before. My feeling is that conventions helps you in merb, but you won't get too much penalty for not following them in merb. However, my experience with Rails is that if you decide not to follow rails convention while developing rails app, it will come back to bite you in one way or another! So think twice when you really attempted to stray away from rails conventions... (This is from my own experience, and of course subjective, but you can think of it as a warning...)
Won't RoR conventions stand in my way?
Because not every database table must
be available for all users, and not
all users can edit all columns and/or
all rows, and the views must be
adapted to my site's look and feel,
etc.
This is a bit of a non-sequitur. Rails is a framework that has been lifted from real world applications. Those applications had to deal with all those issues also, as well as others you may not have thought of yet. Generally, the conventions make life easier once you learn them.
Another point is that the conventions are merely conventions. You don't have to follow them. You do not even have to use RoR for everything, though I've yet to find a case where I didn't/couldn't, I do generally try to push as much into the DB or cache layers as possible.
I don't believe that you'll ever have a serious problem with Rails conventions. Just stick with the conventions and trust the RoR system. The people behind Rails put a lot of effort into these conventions to support 99% of the common usage scenarios.
If you really need to do something outside the conventions it will eventually get complicated quite fast. However, you are not alone. There are a lots of excellent resources on the net to get help (for example the StackOverflow community).
To sum it up:
Stick with the conventions whenever possible (excellent resource to get started: Rails Guides.
Don't reinvent the wheel. Look for Rails plugins and Ruby Gems instead (don't forget GitHub).
Consult the StackOverflow community if you need something out of the ordinary.
Test all the f***ing time (just for fun).
Duplicate: Django or Ruby-On-Rails?
I have been reading on Ruby on Rails, and it seems like on some threads, some users like Django a lot too?
Can someone who have used both give some insight about using them, such as
ease of use
productivity
fun factor
deployment issues
or any other framework you'd highly recommend?
Both are excellent frameworks. Though, I've found Rails to be more suited for the agile developer. For the most part, you'll run some generators to get the files you need as placeholders for your code. Things will work right away, and you just build up from these conventions. It's really flexible and has a large community, lots of innovation and interesting practices are being put into Rails. It's development cycle seems faster paced than Django.
After only touching the surface with Django, it has some interesting differences. As far as I know, you don't get the schema migrations like Rails has out of the box. But you get an extremely simple CRUD mechanism for your models with the extensible admin interface, which is great for testing/managing content. The entire project is documented really well, from the Django Book to the vast amount of information on docs.djangoproject.com.
I personally prefer the Rails way of doing things. But honestly, you need to try them both to see what works for you, and since we're talking about two very good, yet totally different frameworks, it's a tough decision to make either way. So, if you already know Ruby or Python well enough, start with what you know and just go from there. Once you understand how one works, you'll be able to evaluate the smaller differences yourself. Hope that helps.