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.
|illusive networks' Deceptions Everywhere||Aug 29, 2016|
|Happy Birthday Linux||Aug 25, 2016|
|ContainerCon Vendors Offer Flexible Solutions for Managing All Your New Micro-VMs||Aug 24, 2016|
|Updates from LinuxCon and ContainerCon, Toronto, August 2016||Aug 23, 2016|
|NVMe over Fabrics Support Coming to the Linux 4.8 Kernel||Aug 22, 2016|
|What I Wish I’d Known When I Was an Embedded Linux Newbie||Aug 18, 2016|
- illusive networks' Deceptions Everywhere
- Happy Birthday Linux
- New Version of GParted
- What I Wish I’d Known When I Was an Embedded Linux Newbie
- All about printf
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Updates from LinuxCon and ContainerCon, Toronto, August 2016
- ContainerCon Vendors Offer Flexible Solutions for Managing All Your New Micro-VMs
- Blender for Visual Effects
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide