Introducing Finger TDD (Rails + Rspec)
For me personally, a rather shabby developer, the process of implementing TDD was difficult and sometimes thorny.
I’ll briefly outline, because the threshold for entering testing is really higher than just sitting down and writing code on RoR. I will do a few, as Pindos would write, highlights.
1. They wrote a falling test, drove rspec, made sure that the test did not pass (red)
')
2. They wrote a piece of code, drove rspec, made sure that the test passes (green)
3. They refactored, made sure that everything is good and the tests do not fall.
4. Sent code in production
Testing starts rather slowly by itself, so people do some tricks: put a spork that keeps the application instance in memory and saves time every time the rail starts. Reducing the time of tests at the time of launch (I have 7-10 seconds) is guaranteed.
UPDATE: As suggested in the comments (oh, glory to Habra), it makes sense to pay attention to zeus .
Further. What autotest did before is now fashionable to do with guard . The bottom line is to monitor file changes and run only those tests that this change concerned, which will obviously speed up getting feedback from testing. Pretty convenient, but the system does not always catch these changes. So, for example, a change in the factory will not lead to tests, for this I once again jerks the modified model spec file and, it seems, went.
Previously, test datasets were stored in YAML files and called fixtures. Each test loaded fixtures from files into the database, and, although they could be downloaded selectively, this procedure was rather slow and resource-intensive. The guys from thoughtbot solved this problem by the fact that the fixtures began to be programmed and called factories. Factories are really much faster and allow you to easily create associated associative instances, variable data sets (sequence), for example, different user emails and other cool things. Now it is still fashionable to use FactoryGirl .
All these technologies also require a good file. With that, sometimes, if it were not for the stacking flow, I would have despaired of using TDD:
for example: stackoverflow.com/questions/8303491/how-do-i-make-sure-the-helpers-and-models-reload-in-rspec-when-im-using-spork
Now it is fashionable to use RSpec, since it is laconic and descriptive than Test :: Unit, which comes bundled with rails. Tests in rspec are called specs (from the word specification). It seems that testing the rail itself now also moved to rspec, I do not know. The most fashionable thing is to get closer to the human language, so that the tests would be like meta descriptions, as if explained with examples how the code should work. The smaller the text of the test itself and the more expressive it is, the better. In this regard, cucumber (cucumber) was very close to me. Now rspec has learned to replace cucumber with a little less than full.
As it is now, people are testing in three directions.
Here we check the correctness of the methods in the models, the validity of the validations.
validate_presence_of (: model) is not included as a fighter with rspec, so you have to install and connect shoulda
and further in spec_helper.rb
Things are checked that create would actually create an object or render 'new' and such
A type test will include a controller call.
and checking the results. For example, in assigns is what should be assigned in the controller method
check that the new template is rendered. This is obvious, but not intuitive.
BDD history is what a feature looks like in the eyes of the customer when translated into the language of the developer. Usually the story is both a description and a piece of code for testing this feature.
This is more Cucumber paraffin, however, rspec in the base installation also creates the spec / request / folder where the integration tests are placed.
I really like the Cucumber approach because it comes to understanding “why this feature is needed” at every glance at the test, since it actually says “why”. But we know that the feature can be done in different ways, as long as the “why” remains the same.
So, the integration test drives a chain of actions using browser emulation.
Most often, that would work such a crap connect gem capybara or webrat, which actually make the browser emulation
Testing usually looks like this:
something like this
visit and have_content comes from the capybara heme.
A little bit about what and how to test. It is necessary to check border cases, for example, if the code should create a user, then check it with two tests:
1. The user is created correctly, we check that the record appeared in the bazka.
2. That we really get an error if the user is not created correctly.
All those who are already testing, well done, and I recommend to start those who still do not.
I’ll briefly outline, because the threshold for entering testing is really higher than just sitting down and writing code on RoR. I will do a few, as Pindos would write, highlights.
Theoretically, the TDD process should look like this:
1. They wrote a falling test, drove rspec, made sure that the test did not pass (red)
')
2. They wrote a piece of code, drove rspec, made sure that the test passes (green)
3. They refactored, made sure that everything is good and the tests do not fall.
4. Sent code in production
Testing starts rather slowly by itself, so people do some tricks: put a spork that keeps the application instance in memory and saves time every time the rail starts. Reducing the time of tests at the time of launch (I have 7-10 seconds) is guaranteed.
UPDATE: As suggested in the comments (oh, glory to Habra), it makes sense to pay attention to zeus .
Further. What autotest did before is now fashionable to do with guard . The bottom line is to monitor file changes and run only those tests that this change concerned, which will obviously speed up getting feedback from testing. Pretty convenient, but the system does not always catch these changes. So, for example, a change in the factory will not lead to tests, for this I once again jerks the modified model spec file and, it seems, went.
Previously, test datasets were stored in YAML files and called fixtures. Each test loaded fixtures from files into the database, and, although they could be downloaded selectively, this procedure was rather slow and resource-intensive. The guys from thoughtbot solved this problem by the fact that the fixtures began to be programmed and called factories. Factories are really much faster and allow you to easily create associated associative instances, variable data sets (sequence), for example, different user emails and other cool things. Now it is still fashionable to use FactoryGirl .
All these technologies also require a good file. With that, sometimes, if it were not for the stacking flow, I would have despaired of using TDD:
for example: stackoverflow.com/questions/8303491/how-do-i-make-sure-the-helpers-and-models-reload-in-rspec-when-im-using-spork
Self testing
Now it is fashionable to use RSpec, since it is laconic and descriptive than Test :: Unit, which comes bundled with rails. Tests in rspec are called specs (from the word specification). It seems that testing the rail itself now also moved to rspec, I do not know. The most fashionable thing is to get closer to the human language, so that the tests would be like meta descriptions, as if explained with examples how the code should work. The smaller the text of the test itself and the more expressive it is, the better. In this regard, cucumber (cucumber) was very close to me. Now rspec has learned to replace cucumber with a little less than full.
As it is now, people are testing in three directions.
1. Model tests, or unit tests
Here we check the correctness of the methods in the models, the validity of the validations.
validate_presence_of (: model) is not included as a fighter with rspec, so you have to install and connect shoulda
gem "shoulda-matchers"and further in spec_helper.rb
require 'shoulda-matchers'2. Tests of controllers, or as they are called, functional
Things are checked that create would actually create an object or render 'new' and such
A type test will include a controller call.
post :create, mymodel: param1and checking the results. For example, in assigns is what should be assigned in the controller method
assigns(:mymodel){ should == MyModel.last }check that the new template is rendered. This is obvious, but not intuitive.
response.should render_template('new')3. Integration tests, bdd history
BDD history is what a feature looks like in the eyes of the customer when translated into the language of the developer. Usually the story is both a description and a piece of code for testing this feature.
This is more Cucumber paraffin, however, rspec in the base installation also creates the spec / request / folder where the integration tests are placed.
I really like the Cucumber approach because it comes to understanding “why this feature is needed” at every glance at the test, since it actually says “why”. But we know that the feature can be done in different ways, as long as the “why” remains the same.
So, the integration test drives a chain of actions using browser emulation.
Most often, that would work such a crap connect gem capybara or webrat, which actually make the browser emulation
Testing usually looks like this:
- fill field 1 with data 1
- push prince submit
- check that data entries appear on the page 1
something like this
visit services_path
page.should have_content(" ")
visit and have_content comes from the capybara heme.
A little bit about what and how to test. It is necessary to check border cases, for example, if the code should create a user, then check it with two tests:
1. The user is created correctly, we check that the record appeared in the bazka.
2. That we really get an error if the user is not created correctly.
All those who are already testing, well done, and I recommend to start those who still do not.
Source: https://habr.com/ru/post/163597/
All Articles