Skip to content

Latest commit

 

History

History
78 lines (69 loc) · 3.88 KB

README.md

File metadata and controls

78 lines (69 loc) · 3.88 KB

Testing with RSpec

  • Avoid the private keyword in specs.
  • Avoid checking boolean equality directly. Instead, write predicate methods and use appropriate matchers. Example.
  • Prefer eq to == in RSpec.
  • Separate setup, exercise, verification, and teardown phases with newlines. Four-Phase Test
  • Use RSpec's expect syntax.
  • Use RSpec's allow syntax for method stubs.
  • Use not_to instead of to_not in RSpec expectations.
  • Prefer the have_css matcher to the have_selector matcher in Capybara assertions.
  • Avoid any_instance in rspec-mocks and mocha; Prefer dependency injection.
  • Avoid its, specify, and before in RSpec.
  • Avoid let (or let!) in RSpec. Prefer extracting helper methods, but do not re-implement the functionality of let. Example.
  • Avoid using subject explicitly inside of an RSpec it block. Example.
  • Avoid using instance variables in tests.
  • Disable real HTTP requests to external services with WebMock.disable_net_connect!.
  • Don't test private methods.
  • Use stubs and spies (not mocks) in isolated tests.
  • Use a single level of abstraction within scenarios.
  • Use an it example or test method for each execution path through the method.
  • Prefer one expectation per it example.
  • Use assertions about state for incoming messages.
  • Use stubs and spies to assert you sent outgoing messages.
  • Use a Fake to stub requests to external services.
  • Use integration tests to execute the entire app.
  • Use non-SUT methods in expectations when possible.
  • Use shared examples to test behavior that should be the same across different implementations or configurations (for example, the React to ERB migration). Preferably, define shared examples in the same file as the specs that use them, rather than in a separate file.

Acceptance Tests

Sample

  • Avoid scenario titles that add no information, such as "successfully."
  • Avoid scenario titles that repeat the feature title.
  • Place helper methods for feature specs directly in a top-level Features module.
  • Use Capybara's feature/scenario DSL.
  • Use names like ROLE_ACTION_spec.rb, such as user_changes_password_spec.rb, for feature spec file names.
  • Use only one feature block per feature spec file.
  • Use scenario titles that describe the success and failure paths.
  • Use spec/features directory to store feature specs.
  • Use spec/support/features for support code related to feature specs.

Unit Tests

Sample

  • Don't prefix it block descriptions with should. Use the indicative mood instead.
  • Use subject blocks to define objects for use in one-line specs. Example.
  • Put one-liner specs at the beginning of the outer describe blocks.
  • Use .method to describe class methods and #method to describe instance methods.
  • Use context to describe testing preconditions.
  • Use describe '#method_name' to group tests by method-under-test
  • Use a single, top-level describe ClassName block.
  • Order validation, association, and method tests in the same order that they appear in the class.