BDD: Adaptation of the Gherkin language for Russian-language projects in Asp.Net

I will write how you can adapt the popular Gherkin test-writing language for Russian-language projects without using third-party libraries, and also share my experience using this approach.
The article is not a translation, it is a description of my point of view from beginning to end. However, Steve Sanderson's blog helped me come to her. I recommend reading his articles, tagged "Testing".

Prologue

TDD approach in software development has deservedly won its place in the sun. Over the course of his life, he gradually rethought, moving from the category of methods for finding bugs to the category of methods for describing the architecture of an application. The next step that organically complements the evolved TDD is BDD - Behavior Driven Development.

The essence of BDD is in the description of the application architecture system in terms of a subject matter expert, not a programmer, which allows speeding up the process of receiving feedback and removing traditional language barriers between software developers and its users.
')
Using BDD, the system can test (or, as they say now, interaction scenarios) not only the programmer who writes the code, but also PM, who is not versed in implementation details, but knows the system well from the user's point of view. For newbies, BDD scripts are the easiest and most natural way to get acquainted with the project documentation.

Recently, BDD is used more often on the Web, mostly due to the fact that its model of scenarios organically fits into the principle of “request-response”.

What it looks like now

The most popular BDD style tools are Cucumber for Ruby and SpecFlow for .NET. Both of them use the Gherkin language. Here's what it looks like. The developer writes the following text:

Scenario: Show logged in user name
Given I am logged in as a user called "Vlad"
When I visit the homepage
Then the page header displays the caption ", Vlad!"


For each action, he also writes the corresponding functions:

Given /I am logged in as a user called "(.*)"/ do |name|
create_user(name)
sign_in_as(name)
end

Then /the page header displays the caption "(.*)"/ do |caption|
page_header.should_contain(caption)
end


Thus, Cucumber or SpecFlow will be able to interpret each step, isolate parameters using regular expressions, and run the corresponding TestFixtures. As a result, we get a test-suit, completely written in human language and understandable to each participant of the project.

For the description of scenarios, the Given / When / Then: Given template sets the initial conditions, When - the operation, Then - the final result. All scripts are compiled into a special .feature file and, as it is easy to guess, relate to a particular feature of the project.

What is this bad

Well, firstly, to use it, you need to install SpecFlow. Moreover, as I will describe below, there is no real need for such a tool, everything can be done using Visual Studio.

Secondly, SpecFlow has problems with the Russian language and in order to properly configure it for the Cyrillic alphabet you need to put a lot of effort. Here you can argue that, they say, we are all IT specialists and we understand English and that we don’t need Russian in the code. This is not true. The Russian language makes it possible to dramatically increase the readability of scenarios and to abandon the painful process of translating the subject language to English.

How can this be done differently?

Very simple. For some time, Visual Studio allows us to name class methods using the Russian language, in fact, this is all we need. The example above can be written like this:

[TestMethod]
public void ___()
{
___("Vlad");
_____();
____(", Vlad!");
}


The Given / When / Then pattern is transformed here to If / When / _. By inertia one could rename this template to If / When / Then, but the writing “When I go to the main page, I see the text“ hello ”on the page” looks much more organic than “When I go to the main page, then I see on the page text...". Thus, the last word "Then" I recommend simply omit to improve readability.

It all works very simply - each test class needs to be inherited from the base class, in which all the necessary Given / When / Then steps are defined.

When writing integration tests, I integrate related features-regions in the test class, which contain scripting functions. Here’s how AccountIntegrationTest looks:



If you have already written integration tests (for example, using WatiN), then you will appreciate how much easier this process is. This is how my script for sending a message via the feedback form used to look like:

[TestMethod]
public void _______()
{
string caption = U.GetRandomString();
string text = U.GetRandomString();

using (IE ie = new IE())
{
U.Logout(ie);
ie.GoToContacts();
ie.TextField("Caption").Value = caption;
ie.TextField("Text").Value = text;
ClickOnSendMessage(ie);
ie.Text.ShouldContain(" ");
Div div = U.GetLastUnreadMailMessageText(ie);
div.Text.ShouldContain(text);
}
}


And this is how it looks now:

[TestMethod]
public void _______()
{
___();
______();
_____("", " ");
_____("", " ");
______("");
__(" ");
__();
____(" ");
}


In some cases, to perform a step, it needs a context — the result of the previous step (“This is an email” contains the text ”uses the result of the“ Administrator: an email ”). It can also be hidden in the base class as a protected object _lastActionResult; and refer to it if necessary.

But that's not all. You can also greatly simplify working with tables. As a rule, it is they who make fine porridge from integration tests. Here is an example of working with a list of uploaded photos in an album (photo files are loaded, which can later be used to edit titles and descriptions):

Conclusion

As you can see, using the IDE itself, you can build a powerful tool for testing and describing your web project using the BDD approach. Over time, you will have a large collection of Given / When / Then-steps in the base class, in which you can build almost any script on the site. Complement your steps library if necessary, and refactor it just as you would refactor normal classes and their methods — these steps should speak to you in the language of domain logic.