There is such a thing as tests in the application, some people think that this is good, it is useful and they need to be written, while others believe that the main thing is that the attachment goes as it should. Well, I will mark it, I try to be all the same from the first team.

Closer to the question, when we write tests is one thing, but there is something that I don’t know the definition of when we write tests for tests, thereby checking our test statistics by percentage. + Everything else is set homebrew (if you have mac), ruby ​​and other attributes.

In principle, it is clear why this is all done, but not quite, plus I would like some additions to study to know how to successfully enter this.

  • Did not understand a little, and here homebrew and ruby? Do your tests install them? - Nick Volynkin ♦
  • @NickVolynkin for the so-called acceptance tests - Morozov

2 answers 2

Acceptance test - acceptance tests. These are tests that test high-level functionality. Usually they are written by user story. In Ruby, these tests are usually written using Cucumber.

Testing tests is something very incomprehensible. Perhaps you meant coverage - Test Coverage. This can be calculated using simplecov.

    Here two concepts stand out that you can google further, if you're interested:

    1. "Setting up a test environment" is also provisioning. Chef or Ansible can be involved here. And you can save the customized environment in the image and drive through Vagrant for example. In some cases, Docker may be useful, but you should think carefully about what you need and whether you need it.
    2. Testing tests - quite a place to be procedure. There are such cases as:
      • testing accumulated helpers, libraries - if you have accumulated complex helpers for Selenium testing ( Capybara ) of the web application pages, you can make a simple (even a static) page to verify that the helpers are not broken
      • Static checking that the library is used correctly: that the deprecated methods are not used, or they adhere to some recommendations or peculiarities of testing a specific application - if you want to suffer, you can screw the rubocop here, but you should be very critical about this garbage, undercut
      • dynamic checking that the library is used correctly: I had a case where someone did not read the docks badly with the syntax factory girl and faker incorrectly generated objects (the names were not unique) - creating thousands of instances of each class managed to find collisions