<\/span><\/h3>\nI’m really fond of tests, which can be read as short documentation and expose the application’s API. To help you to cope with it, run your specs with the --format d[ocumentation]<\/code> option. The output will be printed in a nested way. If you don\u2019t understand what your code can do, you should rewrite your tests. In order not to write RSpec options every time when running specs, create a .rspec<\/code> configuration file in your home or application directory. (Options that are stored in .\/.rspec<\/code> take precedence over options stored in ~\/.rspec<\/code>, and any options declared directly on the command line will take precedence over those in either file.) The .rspec<\/code> file will look as shown below.<\/p>\n\n--<\/span>color<\/span>\r\n--<\/span>format<\/span> d<\/span>[<\/span>ocumentation<\/span>]<\/span><\/code><\/pre>\n<\/figure>\n <\/p>\n
<\/span>RSpec\u2019s built-in expectations<\/span><\/h3>\nAvoid using !=<\/code> and remember about should_not<\/code>. To test the actual.predicate?<\/code> methods, use actual.should be_[predicate]<\/code>.<\/p>\n\nactual<\/span>.<\/span>should<\/span> be_true<\/span> # passes if actual is truthy (not nil or false)<\/span>\r\nactual<\/span>.<\/span>should<\/span> be_false<\/span> # passes if actual is falsy (nil or false)<\/span>\r\nactual<\/span>.<\/span>should<\/span> be_nil<\/span> # passes if actual is nil<\/span>\r\nactual<\/span>.<\/span>should<\/span> be<\/span> # passes if actual is truthy (not nil or false)<\/span><\/code><\/pre>\n<\/figure>\nPlease also use collection\u2019s matchers.<\/p>\n\nactual<\/span>.<\/span>should<\/span> include<\/span>(<\/span>expected<\/span>)<\/span>\r\nactual<\/span>.<\/span>should<\/span> have<\/span>(<\/span>n<\/span>).<\/span>items<\/span>\r\nactual<\/span>.<\/span>should<\/span> have_exactly<\/span>(<\/span>n<\/span>).<\/span>items<\/span>\r\nactual<\/span>.<\/span>should<\/span> have_at_least<\/span>(<\/span>n<\/span>).<\/span>items<\/span>\r\nactual<\/span>.<\/span>should<\/span> have_at_most<\/span>(<\/span>n<\/span>).<\/span>items<\/span><\/code><\/pre>\n<\/figure>\n <\/p>\n
<\/span>mock_model<\/code> vs. stub_model<\/code><\/span><\/h3>\nBy default, mock_model<\/code> produces a mock that acts like an existing record (persisted()<\/code> returns true). The stub_model<\/code> method is similar to mock_model<\/code> except that it creates an actual instance of the model. This requires that the model has a corresponding table in the database. So, the main advantage is obvious, tests written with mock_model<\/code>, will run faster. Another advantage of mock_model<\/code> over stub_model<\/code> is that it\u2019s a true double, so the examples are not dependent on the behavior\/misbehavior or even the existence of any other code.<\/p>\nUsage of the mock_model<\/code> method is quite simple and is illustrated below.<\/p>\n\ndescribe<\/span> SpineData<\/span> do<\/span>\r\n let<\/span>(<\/span>:user<\/span>)<\/span> {<\/span> create<\/span> :user<\/span> }<\/span>\r\n\r\n before<\/span>(<\/span>:each<\/span>)<\/span> do<\/span>\r\n SpineData<\/span>.<\/span>stub_chain<\/span>(<\/span>:controller<\/span>,<\/span> :current_user<\/span>).<\/span>and_return<\/span>(<\/span>user<\/span>)<\/span>\r\n end<\/span>\r\n\r\n # ...<\/span>\r\n\r\n context<\/span> \"dealing with content set\"<\/span> do<\/span>\r\n let<\/span>(<\/span>:set<\/span>)<\/span> {<\/span> mock_model<\/span> ContentSet<\/span> }<\/span>\r\n\r\n describe<\/span> \".set_updater\"<\/span> do<\/span>\r\n subject<\/span> {<\/span> SpineData<\/span>.<\/span>set_updater<\/span> set<\/span> }<\/span>\r\n\r\n it<\/span> {<\/span> should_not<\/span> be_blank<\/span> }<\/span>\r\n its<\/span>([<\/span>:id<\/span>])<\/span> {<\/span> should<\/span> ==<\/span> set<\/span>.<\/span>id<\/span>}<\/span>\r\n end<\/span>\r\n end<\/span>\r\nend<\/span><\/code><\/pre>\n<\/figure>\n <\/p>\n
<\/span>subject<\/code> and it {}<\/code><\/span><\/h3>\nIn an example group, you can use the subject<\/code> method to define an explicit subject for testing by passing it a block. Now, you can use the it {}<\/code> constructions to specify matchers. It\u2019s just concise!<\/p>\n\ndescribe<\/span> AccountProcessing<\/span> do<\/span>\r\n include_context<\/span> :oauth_hash<\/span>\r\n\r\n # ...<\/span>\r\n\r\n\r\n context<\/span> 'user is anonymous'<\/span> do<\/span>\r\n let<\/span>(<\/span>:acc_processing<\/span>)<\/span> {<\/span> AccountProcessing<\/span>.<\/span>new<\/span>(<\/span>auth_hash<\/span>)<\/span> }<\/span>\r\n\r\n # ...<\/span>\r\n\r\n describe<\/span> '#create_or_update_account'<\/span> do<\/span>\r\n subject<\/span> {<\/span> acc_processing<\/span>.<\/span>create_or_update_account<\/span> }<\/span>\r\n it<\/span> {<\/span>