At the Forge - RSpec
you need to make it:
class Person < ActiveRecord::Base validates_presence_of :first_name end
I save this change, run rake spec again, and sure enough, I get:
Finished in 0.070752 seconds 2 examples, 0 failures
What's next? Now I can move on to the other fields, one by one, in order to test them. And indeed, this back and forth is precisely the way you want to work when you're programming in TDD/BDD fashion. You add a spec indicating what the object should do, watch the spec fail and then add the appropriate line or lines for it to work that way.
You can get a bit fancier than merely checking whether attributes exist. RSpec's should method is very powerful, allowing you to check equality (==), numeric comparisons (< and >) and regular expression matches, among other things.
When using RSpec on models, to a large degree, you can rely on the built-in validations that Rails provides. For example, you presumably want the sex field to contain either an M or an F. If someone enters a value other than that, you should not save it to the database. The first step toward such a feature is the introduction of a new spec:
it "should forbid characters other than M and F" do @valid_attributes[:sex] = 'Z' p = Person.new(@valid_attributes) p.should_not be_valid p.save.should == false end
I run rake spec, and find that this test fails. Again, that's to be expected, and now I can modify my Person class such that it is more restrictive:
class Person < ActiveRecord::Base validates_presence_of :first_name validates_inclusion_of :sex, :in => %w(M F), :message => "Sex must be either M or F" end
When I run rake spec, I get a failure, but not from this latest spec, which passed just fine, telling me that Z is illegal. Rather, what fails is the first spec, in which @valid_attributes has set the key sex to the value for sex. Once again, that's fine; the fact that I have moved forward in small, incremental steps gives me a chance to identify such issues and fix them, before things get too out of hand. By modifying @valid_attributes such that it uses an M (or an F, if you prefer), the specs work.
RSpec offers a refreshingly different, but still somewhat familiar, approach to issues of testing. By thinking in terms of behavior and specifications, rather than configuration and internals, it becomes easier to create tests. The natural “describe”, “it” and “should” terms used in RSpec were chosen carefully, and they help turn testing into a joint venture among all parties, not just programmers.
Although I covered only built-in RSpec matchers (that is, the test that comes after should), it is possible, and even encouraged, to create your own custom matchers for objects in your project.
Next month, I'll continue exploring RSpec by looking at the ways you can test controllers. This raises a number of questions and issues, including those having to do with model objects that are instantiated while inside a controller. As you will see, RSpec's “mock objects” will make this problem much less painful than it otherwise might be.
The home page for RSpec is rspec.info, and it contains installation and configuration documentation, as well as pointers to other documents. The Pragmatic Programmers recently released a book called The RSpec Book, written by RSpec maintainer David Chelimsky and many others actively involved in the RSpec community. If you are interested in using RSpec (or its cousin, the BDD tool Cucumber), this book is an excellent starting point. An RSpec mailing list, which is helpful and friendly but fairly high volume, is at groups.google.com/group/rspec.
Reuven M. Lerner, a longtime Web/database developer and consultant, is a PhD candidate in learning sciences at Northwestern University, studying on-line learning communities. He recently returned (with his wife and three children) to their home in Modi'in, Israel, after four years in the Chicago area.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Django Models and Migrations
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Huge Package Overhaul for Debian and Ubuntu
- Home Automation with Raspberry Pi
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development