Skip to content

Latest commit

 

History

History
21 lines (21 loc) · 2.42 KB

user_spec_annotations.md

File metadata and controls

21 lines (21 loc) · 2.42 KB
  1. Your descriptions should read like a sentence beginning with "It". If testing an actual instance method, use #method_name in your descriptions.
  2. Use factories when you need to build or create an actual object.
  3. This expect statement doesn't quite match the description. Ensure your description and assertion are the same.
  4. Again, factories.
  5. If you're going to use the new expect syntax, use it consistently.
  6. Most tests should be isolated enough that you only need to make one assertion per test. If the tests are examining the same object, use subject for added conciseness.
  7. This should, again, use a Factory. In any case, calling bang methods in poorly-written tests might raise exceptions that obscure the actual reason for a failed test.
  8. This assertion is not testing what is indicated in the description.
  9. Don't comment out tests. Alias xit to ignored tests in your RSpec config to quickly toggle a test to an ignored state.
  10. Contexts should be descriptive and generally refer to a state or condition. They are not a catch-all organizational tool.
  11. There is rarely a good reason to use before(:all). Favor let and let! for simple instantiation of objects instead of instance variables.
  12. There is no need to persist this object. Use mocks/stubs when the object's properties are irrelevant in the testing context.
  13. This is another opportunity to use let. If a part of your test suite requires a complex setup procedure, those tests probably aren't sufficiently isolated. At the very least, move complex setup code into an included module.
  14. Database transactions are slow. Don't persist more objects than you need to. With proper use of factories and mocks, this often means that you don't need to persist anything!
  15. When creating objects for shared use among tests, make sure all tests in that context actually need those objects, since these objects are repeatedly destroyed and recreated.
  16. Examine only one behavior per test.
  17. Use describe instead of context to group tests if referring to an actual method or functionality.
  18. This is another example of a description in need of rewriting.
  19. Are you testing the functionality of the instance method or the code in the before(:each) block? Keep your tests simple and isolated.
  20. Use a describe '#has_orders' block to contain tests relating to a single instance method.
  21. If there is a built-in matcher available, like be_true, use it.