# Проверить код тестов перед передачей на ревью --- <!-- Put the link to this slide here so people can follow --> Источник: [Slack](//https://appulate.slack.com/archives/GPXVAJ550/p1581519923110800) --- ### Сначала делаем код работоспособным, потом смотрим на готовый вариант взглядом критика и улучшаем🧙‍♂️: 1. Придерживаемся **[правил именования переменных](https://www.c-sharpcorner.com/UploadFile/8a67c0/C-Sharp-coding-standards-and-naming-conventions/)** в зависимости от [модификатора доступа](https://docs.microsoft.com/ru-ru/dotnet/csharp/language-reference/keywords/accessibility-levels). ![](https://i.imgur.com/dADKzXo.png) 2. Даем содержательные имена обычным и тестовым методам. Имя тестового метода в идеале - краткое предложение, описывающее суть проверки. Над *емкими* и *понятными* именами иногда приходится потрудиться, однако коллеги, работающие с кодом автотестов, будут вам благодарны😺 3. Проверяем, не используются ли переменные только 1 раз. Если такие есть, пытаемся использовать их значение сразу в месте вызова. #### Например: ```csharp= int firstItem = testArray[0]; int secondItem = testArray[1]; if (firstItem == secondItem ) { ....} // больше firstItem и secondItem никто не видел... ``` можно заменить на ```csharp= if (testArray[0]== testArray[1]) ``` Если получается читаемая конструкция - хорошо, если нет - можно вернуть переменную. 4. Используем свойства там, где хочется сделать **private** поле публичным: https://metanit.com/sharp/tutorial/3.4.php 5. Если в теле метода содержится подсчет одного выражения, можно пользоваться оператором: ```csharp= => ``` подробнее **[здесь](https://docs.microsoft.com/ru-ru/dotnet/csharp/language-reference/operators/lambda-operator#expression-body-definition)** 6. Если читаемость кода не страдает, вместо кострукций ```csharp= if {...} else {...} ``` используем оператор ```csharp= ? ``` подробнее **[здесь](https://docs.microsoft.com/ru-ru/dotnet/csharp/language-reference/operators/conditional-operator)** ### Cознательно фейлим написанный тест Чтобы увидеть, прочитать сообщение об ошибке и задаться вопросом: -Понятно ли оно? -Содержит ли нужную информацию? ### Помним о договоренностях внутри команды автоматизации Используем **unexpected** вместо **incorrect** в сообщении **assert-а**. Идея в том, что тест не может сказать, что поведение неправильное (возможно оно поменялось по новым требованиям, а тест устарел). Тест может только ожидать/не ожидать чего-то. Вернее написать что-то вроде: **"Element title is not expected"**, чем **"Element title is incorrect"** ###### tags: `Principles of work` `E2E` `guide` `best-practice`