Dear taxi drivers, we have good news!
Advertisers' Contest
The contest runs from October 27 to November 4 (20:00 Moscow time).
Replenish your advertising account, take a prize place, and get a bonus to the amount of replenishments up to 100%!
How we developed Tasks
We want to share with you information about what is under the hood of some sections of Taxi-money. Today we will tell you how tasks were made in Clicks.
In the new section of Clicks, we used the method - development through testing.
This is a type of development when tests are written first and then the program itself.
That is, a specification for the program is written, it describes what functions the program will have, how they will work, what they will respond to and, most importantly, how.
The specification is worked out in detail, all possible situations, failures,
incorrect responses from other subsystems, lack of responses are taken into account.
For each type of failure, the program behavior is predicted and included in the specification.
A lot of specifications are written, for different parts of the system, the main thing is that the specification does not "grow".
Next, tests are written according to this specification.
Tests are a set of scripts that check whether the code works correctly.
And how is the check carried out? Very simple - this is, in fact, emulation of user actions.
To check whether the program works correctly,
- it is necessary to emulate user actions.
In this case, you need to emulate with different input data (with correct data, with erroneous).
Actual results need to be compared with expected ones.
Let's look at an example:
Let's take the "Task activation" function, in essence, this is just a change in the task status, but under the hood there are many logical points that either allow you to activate the task or not.
If the task has a sufficient balance, then you can run it. If the task has not been checked by the moderator, then you cannot run it. And so on down the list.
The test creates a task, fills it with data "at random" and carries out operations to identify potential errors.
Let's say it tries to activate the task BEFORE the moderator has checked it.
And if suddenly the response is successful (that is, the task was activated) - this means that there is an error in the system, because an unverified task should not be allowed to the general list.
Or it tries to activate a task with a zero balance on the account.
And so on down the list, several tests are written for each function of the system.
Before publishing on the site, we run all the tests, and if suddenly one of them "failed" (reported an error), then the problem is investigated and corrected.
This type of development allows us to be more confident that the system as a whole works normally and there are no critical errors.
Of course, this does not exclude errors at all, but significantly reduces their number to zero.
Unfortunately, this development method is much slower and more labor-intensive. After all, now you need to develop several programs at once - one does the work, and the other tests the first.
But we believe that by providing a higher-quality product to our users, we allow them to work with the site without errors, stress, and simply a bad mood.
And this is sometimes much more expensive than the time spent by programmers.
We can already say that this method has brought us significant dividends - the number of critical errors after publishing tasks is zero.
Of course, there were errors in those parts of the system that were not covered by tests, but these were minor errors that did not affect the overall performance.
In future sections we will use this method to allow our users to enjoy our work without annoying bugs.
Stay with the best project of RUnet!
