-
Notifications
You must be signed in to change notification settings - Fork 5
Unit Testing with QED
trans edited this page Sep 13, 2010
·
3 revisions
Given it’s literate nature you might think QED is not suited to Unit Testing, but in fact it can do unit testing fairly well —if not as well as any other framework (expect perhaps Lemon).
Consider a clear example:
= Test Case for Roll::Version Load the library. require 'roll/version' Method #to_s: v = Roll::Version.new('1.2.3') '1.2.3'.assert == v.to_s Method #to_str: v = Roll::Version.new('1.2.3') '1.2.3'.assert == v.to_str Method #[]: v = Roll::Version.new('1.2.3') 1.assert == v[0] 2.assert == v[1] 3.assert == v[2] Method #<=>: v1 = Roll::Version.new('1.2.3') v2 = Roll::Version.new('1.2.4') (v2 <=> v1).assert == 1 Method #=~ (pessimistic constraint): v1 = Roll::Version.new('1.2.4') v2 = Roll::Version.new('1.2') assert(v1 =~ v2) Method #major: v = Roll::Version.new('1.2.3') v.major.assert == 1 Method #minor: v = Roll::Version.new('1.2.3') v.minor.assert == 2 Method #patch: v = Roll::Version.new('1.2.3') v.patch.assert == 3 Method #parse_constraint: a = Roll::Version.parse_constraint("~> 1.0.0") e = [ "=~", Roll::Version['1.0.0'] ] e.assert == a
And, of course, one could easily extend that to further describe each method with “… should do such and such…”.
For the really clever, you could create an applique to match the class/module and each method name and track if every method was covered, and dump a message about it at the end of the test run. How cool is that? I’ll leave it as an exercise for the reader.