Im a beginner when it comes to TDD and BDD.
This is what I know:
To use TDD in Rails I use it's built-in unit-, functional and integration tests.
To use BDD in Rails I use Cucumber.
So are these two different techniques that shouldn't be used together?
If I use TDD, then I shouldn't use BBD/Cucumber and vice versa?
Please enlighten me on this topic.
Thanks
Not that I'm a genius at this but here's my humble answer.
Cucumber is great for outline the behavior of your site, incorporating the business solutions and the code together and developing the site properly from it.
Then after this is complete, you create Rspecs to test how data holds in your MVC. Rspec is great for models.
I've been recommended using Factory-Girl for testing controllers.
In conclusion, using all of these provides a very rounded series of tests to ensure that first your business solutions are being met, and second that your architecture can withstand the many angles that can be tested with rspec and factory-girl.
I've found that getting the right mix of what to when and why was the toughest part, given that there is often too much information on the net. A good blog post is Outside in BDD which takes you on a journey of testing using Cucumber and RSpec.
The author, Sarah Mei, explains the flow that a developer would undertake to use BDD/TDD and highlights some caveats on testing Controllers, Models and Views.
I tend to agree that Rspec is good for the models, more so when you have custom behaviour that is beyond what Rails gives you out of the box. This comes out in the RSpec & Cucumber books, it's just that it takes a while to find that gem of information about testing what, when and why !
Related
I want to learn how to write unit tests for a Rails App. Where do I start? All the tutorials on Google are old, back from 2007, and there seem to be an abundance of choice but not a preferred solution.
Right now most people seem to be using Rspec for unit testing and Cucumber for integration testing. You can see a fairly recent poll here where 87% chose Rspec in a survey.
A great book for Rspec and Cucumber is The Rspec Book written by the current maintainer of Rspec. It goes over both Rspec and Cucumber.
Railscasts also has a few relevant screencasts. Cucmber1, Cucumber2
Many people seem to love Cucumber but it doesn't seem as useful if you don't have a client you're doing work for. Most of my projects are side projects I do myself so these days I'm looking into Steak instead of Cucumber. This will allow me to use Rspec for unit tests and Steak for integration tests and reduces some complexity/tedium that is introduced when using Cucumber.
People have said that it doesn't really matter which testing framework you pick, it's more important that you START TESTING. I agree with that but hopefully these resources will help you get started.
However, one thing you probably want to avoid from the very start are fixtures. Use factories instead and check out this Railscasts episode on it.
UPDATE: Steak is no longer necessary and the same functionality is baked into Rspec.
I'd suggest starting with the Rspec Book by David Chelimsky and friends. It goes over the various types of testing, why you should test and runs through various examples that show you good practices as well as giving you guidelines for what to avoid.
Rspec is very popular and preferred by many over the default rails test suite. Most material I've read that goes over using the default test suit ends with an introduction to Rspec and how it makes life simpler.
If you want to do it the proper way, you should use others testing frameworks like Rspec, Cucumber or shoulda. This way you will write Unit Tests in a BDD context. Those frameworks are recent so obviously the documentation that you will find about them are recent enough! Finally, I'd suggest you to read this great blog post from Sarah Mei about the outside-in approach combining Rspec/Cucumber, that's how I was convinced to use these frameworks, she really explains very well how you should approach the tests!
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 have been trying to determine a good way to test rails apps, covering all relevant aspects... since I have no experience writing tests at all I have been looking at railscasts.com which seems like a pretty good resource to learn basic stuff for rails. but for tests I have found several episodes, some using rails unit test classes, others use Cucumber, RSPEC, ZenTest, Autotests, Webrat, Selenium, etc.
So Im now just not sure if Im supposed to pick one of these or a combination. are some of these now old and obsolete?? are they mutually exclusive?... basically I want to learn testing for rails and would like to hear opinions on how to properly and sufficiently test rails apps and what framework to use for the different types of tests
please help, thanks in advance
ps. if someone can provide a good resource for learning the difference between unit tests, integration tests and so on I'd appreciate it.... I know I didnt do TDD or BDD cause my app is pretty much done now, and all seems to be working just fine. but I still would like to add tests for learning purposes and future developments.
http://guides.rubyonrails.org/testing.html
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.
Everyone is talking about TDD (BDD) in Rails (and not just Rails) development world today. It's easy to find plenty of good general information about it, there are quite a few tools you can use for this purpose and there are many (good) examples of how to use them.
Now, I'm already on the train. I like the idea (never did TDD before) and I decided to go for Shoulda (because it seems to me quite easy to understand). I read plenty of examples and have done some first tests. My problem is this: I'm just not sure if I'm doing it right. As I said, there are many tiny examples all over the net, but I haven't found any comprehensive guide covering overall workflow of TDD with Shoulda.
Here are my questions:
What is your way of practising TDD with Shoulda? (What is your usual workflow throughout one iteration?)
What other tools do you use (except of Shoulda itself)?
Any other tips?
I'm using RSpec instead of shoulda, (although I believe that shoulda can be used with RSpec) and the biggest improvement to my workflow has come from using Autotest and then RSpactor.
These tools automatically monitor your source tree for changes and execute the relevant tests if update either the test or implementation file. A pretty small change to the testing practice but the immediate feed back has increased my discipline in writing tests for every piece of functionality.
+1 for Autotest.
If you have a large test suite and only want to run the test you are working on (as opposed to the whole test suite) check out this monkey patch for Autotest.
As for other tools you should check out Factory Girl as a fixtures replacement.
Most of what I know about using Shoulda came by reading others test code. Check out some of Thoughtbot's projects on github, such as Clearance and Pacecar.
I totally agree that there is a significant gap in the rails BDD documentaion. Lots of little examples but no big ones giving an overall picture of how to do it. Even the books that have chapters on testing are guilt of this. The only full examples I have seen are peepcode's three part screencast on rspec and a video on confreaks about flex mock.
I'd love to hear about other good resources on BDD that go beyond minor examples of syntax and I'd really like see a book on the topic.