How to choose a name for a unit test?

Before the very first "modular test"

Need to negotiate with yourself or the team about what to consider as a “unit test”?

For example, in Roy’s book (see the “Recommended Literature” section) a clear definition of “unit” is given and quite convenient for a programmer.

Without a clear and confident understanding of what a "unit" is, I strongly do not recommend writing unit tests. Even if your understanding of what a unit test is different from what Roy says, it still needs to be unified and stable for YOU or your team. Which requires some agreement.

Understanding "Modular Test" by Roy :

Roy, in my opinion, offers the most convenient and practical naming scheme:

{unit-of-work} _ {scenario} _ {expected-results-or-behavior}

Where: unit-of-work - this is exactly what you mean by 'unit' or as agreed with the team. scenario is a specific action on a test object. expected-results-or-behavior - these are your expectations as to what should happen

Examples:

1. jsonParse_InvalidFileExtension_ThrowInvalidLogFileException

It is immediately obvious that the parser of the json document is checked on a file with an invalid file extension and therefore an InvalidLogFileException must be thrown.

2. opimizeByteCode_UnknownInstruction_ReturnMinusOne

Here you can see that when optimizing bytecode, -1 will be returned if an unknown instruction is encountered

Writing unit tests with difficult conditions

1. This is a completely different question.
2. In short, in one unit test ONE check. If the condition is difficult, then there are several conditions, and therefore it is necessary to take and break into several checks - unit tests
3. In any test there should be no conditional logic. If there are two branches in the production code, one if-part, the other else-part. So it is written two modular test.

etc. etc. But it's all a topic for another discussion.

Recommendations on the names of tests of the author

testCustomerRedirectUrlAfterSelectLastTransactionProcessShouldContainsUrlToConfirmRecurringProfilePageWhenTransactionTypeIsCreateRecurringProfile

What is wrong, in my opinion, in your test:

1. The prefix is ​​'test'. If I watch a test project with a set of unit tests and when I see something, then what is it if not a test? In C # there is [Test] , in python there is py.test . It's enough!
2. The name is not divided into logical parts. Where is the action? Where is the condition? Where is the expected result? And where are we testing? All mixed up in one pile! Any programmer either is too lazy to read such a name, or will begin to divide into parts and not the fact that he will divide it as the author of the test divided into parts!
3. The word 'when' is superfluous! If you have an accepted naming scheme, then you or your colleague so know where to look for a condition or an action!

Recommended reading :

1. I strongly recommend downloading, and it is better to buy the book Art Of Unit Testing. Even if Suddenly do not write in C #. Knowledge is helpful!

2. Answer SO-Member @Timofey Bondarev to my question. How do I replace the prefix 'test_' with 'should_' in unit tests with the use of unittest?

1. Test names must be strings

We need to start by saying that the name of the test is the name of the function. Unlike functions, we do not call tests from the code; the name of the test is only needed to describe what it tests once, so that this description is then written to the log with the test results.

Therefore, in some test frameworks, test names are regular strings.
For example in Catch (C ++)

 TEST_CASE("что-то когда такие-то условия") { auto testee = Testee(1, 2); REQUIRE(testee.foo() == 1); } 

Or Mocha (JS and other * script)

 describe('что-то', function () { it('когда такие-то условия', function () { var testee = Testee(1, 2); assert.equal(testee.foo(), 1); }); }); 

An interesting exception is languages ​​where identifiers can have any characters, such as in F #

 [<Test>] let ``twice удваивает числа`` () = twice(1) |> should equal 2 

2. No need to repeat (DRY principle)

If the test framework allows you to group tests, then this should be used. Instead of tests Чтото_КогдаЭто_ВотЭто , Чтото_КогдаДругое_ВотЭто and Чтото_КогдаДругое_ЕщеИЭто tests can be grouped.
Mocha / JS example:

 describe('что-то', function () { var testee = Testee(); describe('когда так-то', function () { it('вот это', function () { testee.setup(1); assert.equal(testee.f(), 1); }); }); describe('когда по другому', function () { testee.setup(2); it('вот это', function () { assert.equal(testee.f(), 20); }); it('и еще это', function () { assert.equal(testee.g(), 21); }); }); }); 

Or for Catch / C ++:

 TEST_CASE("что-то") { auto testee = Testee(); WHEN("когда так-то то вот это") { testee.setup(1); REQUIRE(testee.f() == 1); } WHEN("когда по другому") { testee.setup(2); THEN("вот это") { REQUIRE(testee.f() == 20); } THEN("и еще это") { REQUIRE(testee.g() == 21); } } } 

It also often does not make sense to repeat the test code in the test name. It is necessary to describe what the test checks, and not how it does it. Therefore, instead of StartButton_WhenPressed_BecomesDisabled, you can write

 TEST_F(ButtonsPanelTest, StartButtonPress) { EXPECT_CALL(delegate_mock, Start()); start_button.Press(); ASSERT_FALSE(start_button.IsEnabled()); } 

Typically, the test includes the initial conditions (GIVEN / WHEN part) and the results (THEN part). If for some initial conditions there is one test, then why not write in the title what is checked in the THEN part. This is evident from the code, and if the test fails, the text of the failed check will be written in the log.

Test Name Examples

Test names depend on the test framework and on the test level (unit / integration / regression).

Mocha / JS Regression Tests

 describe("File IO", function() { it("can read text", function() {...}) it("invalid file name error", function() {...}) it("read after EOF error", function() {...}) }) 

Unit tests on Catch / C ++, when Catch uses split test names /

 TEST_CASE_METHOD(ParserFixture, "Notifications/Empty") { SECTION("no 'type' field") {...} SECTION("empty updates") {...} } TEST_CASE_METHOD(ParserFixture, "Notifications/Status update") {...} TEST_CASE_METHOD(ParserFixture, "Notifications/Profile update") {...} 

Newer Catch / C ++ tests tagged

 TEST_CASE("request line", "[http][parser]") {...} TEST_CASE_METHOD(FrameReceiverFixture, "is frame complete", "[websocket]") {...} 

Tests for gtest / C ++ (from Chromium code)

 TEST_F(DownloadItemTest, CompleteDelegate_SetDanger) {...} TEST_F(DownloadItemTest, NotificationAfterOnDownloadTargetDetermined) {...} 

Tests on Golang

 func TestSomeClassMethod_CanDoThis(t *testing.T) {...} 

If the test name cannot be specified as a string, then the simultaneous use of CamelCase and underscore gives a fairly good readability. For example, instead of TEST_CASE("some unit") { WHEN("this state") { THEN("those results") { ... you can write SomeUnit_WhenThisState_ThoseResults .

A very long test name can be considered a diagnostic signal. Such signals can be viewed from different points of view, but in any case, as a rule, they indicate the presence or possible occurrence of a problem. The minimum possible options:

• The test code implements the wrong architecture.
• This is not a modular, but perhaps an integration test.
• Incorrect implementation of the actual test module
• The developer did not get enough sleep and (or) used any transformers of consciousness in excess

Since you gave an example, let's look at it. To begin with, I will try to extract from the English the names of your test Russian meaning:

"Make sure that the URL to which the client is redirected after processing the last transaction should contain the URL corresponding to the return profile page if the transaction type implements the return profile."

Let's assume what the actual body of such a test might look like:

 [Test] public void redirect_to_profile_url_test() { Transaction trn = new TransactionCreateRecurringProfile(); this.executionContext.Add(trn); this.executionContext.ExecuteTransaction(); Assert.AreEqual(this.recurringProfileUrl, this.executionContext.RedirectUrl); } 

In the first approximation, everything seems brief, pretty and readable. Let's suppose what a test might look like that certifies the opposite:

 [Test] public void do_not_redirect_to_profile_url_test() { Transaction trn = new TransactionDoesNotCreateRecurringProfile(); this.executionContext.Add(trn); this.executionContext.ExecuteTransaction(); Assert.AreNotEqual(this.recurringProfileUrl, this.executionContext.RedirectUrl); } 

Naturally, we assume that all the preparatory work before the test is taken from the actual tests:

 [TestFixture] public class RedirectAfterTransactionTest { private ExecutionContext executionContext; private String recurringProfileUrl; [SetUp] public void setUp() { this.executionContext = new RealExecutionContext(); this.recurringProfileUrl = "http://localhost/bla-bla-bla"; } } 

Update

What do I call tests? Something like this (from the working draft):

 public class InMemoryRepositoryTest { @Test public void insert_test() {} @Test public void find_test() {} @Test public void delete_test() {} @Test public void update_data_with_same_id_test() {} @Test public void cant_update_if_item_with_id_not_exists_test() {} @Test public void do_not_insert_other_type_data_test() {} @Test public void insert_with_merge_test() {} @Test public void update_with_merge_test() {} } 

The name of the test class refers to the name of the class being tested in the code. And the names of test methods indicate the names of the tested methods in the test class and try to briefly report on the testing conditions of each specific method.

I prefer not to get too carried away with the details in the names of test methods, because as the code refactor, the name of the method can get out of sync with the content. This is especially true when the project is being made up under strong temporary pressure from the customer.

Naming rules are some kind of Tao or Kung Fu ... Balance must be maintained. If the name of the test method is longer than the code itself contained in the test method, then the developer who refactor the method may be easier and faster to read and understand the code than to wade through the literary twists and turns of the name in English.

Думаю, тестовые методы тут не стоит выделять отдельно - в целом они подчиняются тем же правилам именования, что и обычные методы. В числе этих правил - не давать методу слишком длинное и неудобочитаемое название. Краткость - сестра таланта, как писал один русский писатель. Для всеобъемлющего описания того, что именно тестирует метод, человечество изобрело комментарии, в которых можно растекаться мыслью по древу (хотя злоупотреблять не стоит и там).

Ваш же вариант именования сильно похож на применявшуюся несколько столетий назад витиеватую манеру давать названия книгам, когда в названии описывается едва ли не весь сюжет книги. Например, полное название Робинзона Крузо звучит устрашающе-длинно:

"Жизнь, необыкновенные и удивительные приключения Робинзона Крузо, моряка из Йорка, прожившего 28 лет в полном одиночестве на необитаемом острове у берегов Америки близ устьев реки Ориноко, куда он был выброшен кораблекрушением, во время которого весь экипаж корабля кроме него погиб, с изложением его неожиданного освобождения пиратами; написанные им самим"

Я считаю что название модульного теста должно быть ёмким. Особенно если тест пишется в BDD стиле. Особенно если ваш фреймворк для тестирования умеет это раскладывать в читабельные отчёты.

Нет никакой разницы, насколько длинное имя метода с точки зрения читающего тест программиста. Есть только один важный аспект, где длина метода будет пропорциональна пониманию, что он тестирует - это отчёт, который будет читать другой человек, не программист.

На мой взгляд ёмкие названия (пример):

• testShouldAlwaysPreparePathsAndConvertThemInToArray
• testShouldRegisterNamespacesForMultipleDirectories
• testShouldThrowExceptionIfDbIsMissingOrInvalid
• testShouldSetOptionsWhenConfigPassedToTheConstructor

В любом приличном фреймворке для тестирования такие имена методов трансформируются в что-то подобное (пример):

 Test should always prepare paths and convert them in to array [OK] Test should register namespaces for multiple directories [OK] Test should throw exception if db is missing or invalid [OK] Test should set option whet config passed to the constructor [FAIL] 

Согласитесь, такое гораздо приятнее читать. Это можно показать кому угодно, ПМ например или фронтенд разработчику : ) и ему совсем не обязательно знать фреймворк, который вы используете или язык.

Не останавливайтесь на длине метода. Делайте его на столько длинным, насколько этого требует сценарий. Да, конечно, в пределах разумного. Несколько не с руки будет читать такой тест, если он из-за ширины экрана, в лучшем случае разобъётся на несколько строк, а то и вовсе обрежется.

I was taught that a unit test always has a name pattern: when

whenThen

 @Test whenStringArgInThenArgAddInArrayList() { Item item = new Item(); item.getList.add("a"); assertThat(item.getList[0].get, is("a")); }