Тестирование Node.js-проектов. Часть 1. Анатомия тестов и типы тестов

2019-01-09 в 9:05, admin, рубрики: javascript, node.js, Блог компании RUVDS.com, Разработка веб-сайтов, тестирование, Тестирование веб-сервисов

Автор материала, первую часть перевода которого мы сегодня публикуем, говорит, что он, как независимый консультант по Node.js, каждый год анализирует более 10 проектов. Его клиенты, что вполне оправданно, просят его обратить особое внимание на тестирование. Несколько месяцев назад он начал делать заметки, касающиеся ценных приёмов тестирования и встречающихся ему ошибок. В результате получился материал, содержащий три десятка рекомендаций по тестированию.

В частности, речь здесь пойдёт о выборе подходящих в конкретной ситуации типов тестов, об их правильном оформлении, об оценке их эффективности, и о том, где именно в CI/CD-цепочках нужно их размещать. Некоторые из приведённых здесь примеров проиллюстрированы с использованием Jest, некоторые — с использованием Mocha. Этот материал, в основном ориентирован не на инструменты, а на методологии тестирования.

→ Тестирование Node.js-проектов. Часть 2. Оценка эффективности тестов, непрерывная интеграция и анализ качества кода

▍0. Золотое правило: тесты должны быть очень простыми и понятными

Знаете ли вы кого-нибудь — друга, члена семьи, героя фильма, кто всегда заряжен хорошим настроением и всегда готов предложить руку помощи, ничего не требуя взамен? Именно так должны быть спроектированы хорошие тесты. Они должны быть простыми, должны приносить пользу и вызывать положительные эмоции. Этого можно достичь путём тщательного отбора методик, инструментов и целей тестирования. Таких, использование которых оправдывает затраты времени и сил на подготовку и проведение тестов и при этом даёт хорошие результаты. Тестировать нужно только то, что нуждается в проверке, надо стремиться к тому, чтобы тесты были бы простыми и гибкими, а иногда от некоторых тестов можно и отказаться, осмысленно пожертвовав надёжностью проекта ради его простоты и скорости разработки.

Тесты не стоит рассматривать как обычный код приложений. Дело в том, что типичная команда, занимающаяся разработкой некоего проекта, в любом случае, делает всё возможное для поддержки его в рабочем состоянии, то есть стремится к тому, чтобы, скажем, коммерческий продукт работал так, как того ждут его пользователи. В результате такая команда может не очень хорошо отнестись к тому, что ей придётся поддерживать ещё один сложный «проект», представленный набором тестов. Если тесты основного кода разрастаются, оттягивая на себя всё больше внимания и становясь поводом для постоянного беспокойства, то работу над ними либо забросят, либо, пытаясь поддерживать на достойном уровне, отдадут им столько сил и времени, что это замедлит работу над основным проектом.

Поэтому код тестов должен быть как можно более простым, с минимальным количеством зависимостей и уровней абстракции. Тесты должны выглядеть так, чтобы их можно было бы понять с одного взгляда. Большинство рекомендаций, которые мы здесь рассмотрим, произрастают из этого принципа.

Раздел 1. Анатомия тестов

▍1. Проектируйте тесты так, чтобы отчёт сообщал бы о том, что тестируется, по какому сценарию, и о том, чего ждут от тестов

Последствия отступления от рекомендаций

Предположим, систему не удалось развернуть и при этом из отчёта о тестировании можно узнать лишь о том, что она не прошла тест, названный Add product, проверяющий добавление в неё некоего товара. Даст ли это сведения о том, что именно пошло не так?

Правильный подход

Сведения о тесте состоят из трёх фрагментов информации.

//1. тестируемый модуль
describe('Products Service', function() {
  //2. сценарий 
  describe('Add new product', function() {
    // 3. то, чего ждут от теста
    it('When no price is specified, then the product status is pending approval', ()=> {
      const newProduct = new ProductService().add(...);
      expect(newProduct.status).to.equal('pendingApproval');
    });
  });
});

Правильный подход

Отчёт о тестировании напоминает документ, содержащий изложение требований к продукту.

Вот как это выглядит на разных уровнях.

Тестирование Node.js-проектов. Часть 1. Анатомия тестов и типы тестов - 2

Документ с требованиями к продукту, именование тестов, результаты тестирования

Документ с требованиями к продукту может представлять собой либо, собственно, специальный документ, либо может существовать в виде чего-то вроде электронного письма.
Именуя тесты, описывая цель тестирования, его сценарий и ожидаемые результаты, нужно придерживаться того языка, который применяется при формулировании требований к продукту. Это поможет сопоставлять код тестов и требования к продукту.
Результаты тестирования должны быть понятны даже тем, кто с кодом приложения не знаком или основательно его забыл. Это — тестировщики, DevOps-специалисты, разработчики, возвращающиеся к работе с кодом через несколько месяцев после его написания.

▍2. Описывайте то, чего ожидают от тестов, на языке продукта: используйте утверждения в стиле BDD

Последствия отступления от рекомендаций

Если не следовать вышеописанным рекомендациям, всё закончится тем, что члены команды разработчиков будут писать меньше тестов и пропускать особо досаждающие им проверки, используя метод .skip().

Неправильный подход

Читателю этого теста придётся полностью просмотреть довольно длинный императивный код только для того, чтобы понять то, что именно проверяется в тесте.

it("When asking for an admin, ensure only ordered admins in results" , ()={
    //предположим, что мы добавили тут двух администраторов — "admin1" и "admin2", и пользователя "user1"
    const allAdmins = getUsers({adminOnly:true});

    const admin1Found, adming2Found = false;

    allAdmins.forEach(aSingleUser => {
        if(aSingleUser === "user1"){
            assert.notEqual(aSingleUser, "user1", "A user was found and not admin");
        }
        if(aSingleUser==="admin1"){
            admin1Found = true;
        }
        if(aSingleUser==="admin2"){
            admin2Found = true;
        }
    });

    if(!admin1Found || !admin2Found ){
        throw new Error("Not all admins were returned");
    }
});

Правильный подход

Понять этот тест можно буквально с одного взгляда.

it("When asking for an admin, ensure only ordered admins in results" , ()={
    //предполагается, что тут добавлены два администратора
    const allAdmins = getUsers({adminOnly:true});
    
    expect(allAdmins).to.include.ordered.members(["admin1" , "admin2"])
  .but.not.include.ordered.members(["user1"]);
});

▍3. Выполняйте линтинг кода тестов с помощью специальных плагинов

Последствия отступления от рекомендаций

Разработчик будет счастлив, видя, что код покрыт тестами на 90% и при этом 100% тестов проходят успешно. Однако в таком состоянии он будет пребывать лишь до тех пор, пока не окажется, что многие тесты, на самом деле, ничего не проверяют, а некоторые тестовые сценарии просто пропускаются. Остаётся лишь надеяться, что никто не станет разворачивать в продакшне проекты, которые «протестированы» подобным образом.

Неправильный подход

Тестовый сценарий полон ошибок, которые, к счастью, можно выявить с помощью линтера.

describe("Too short description", () => {
  const userToken = userService.getDefaultToken() // *error:no-setup-in-describe, use hooks (sparingly) instead
  it("Some description", () => {});//* error: valid-test-description. Must include the word "Should" + at least 5 words
});

it.skip("Test name", () => {// *error:no-skipped-tests, error:error:no-global-tests. Put tests only under describe or suite
  expect("somevalue"); // error:no-assert
});

it("Test name", () => {*//error:no-identical-title. Assign unique titles to tests
});

▍4. Придерживайтесь метода «чёрного ящика» — тестируйте только общедоступные методы

Последствия отступления от рекомендаций

Тесты, которыми пытаются охватить внутренние механизмы некоей системы, ведут себя как мальчик-пастух из басни, который сзывал крестьян криками «Помогите! Волк!», когда никакого волка поблизости не было. Люди сбегались на помощь лишь для того, чтобы обнаружить, что их обманули. А когда волк и правда появился, никто уже на помощь не пришёл. Такие тесты выдают ложноположительные результаты, например, в тех случаях, когда меняются имена каких-то внутренних переменных. В результате неудивительно то, что тот, кто проводит эти тесты, скоро начинает игнорировать их «крики», что, в конечном итоге, приводит к тому, что однажды незамеченной может оказаться настоящая серьёзная ошибка.

Неправильный подход

Этот тест проверяет внутренние механизмы класса без особой причины для таких проверок.

class ProductService{
  //Этот метод используется лишь внутри класса
  //Изменение его имени приведёт к тому, что тест сообщит об ошибке
  calculateVAT(priceWithoutVAT){
    return {finalPrice: priceWithoutVAT * 1.2};
    //Изменение формата результата или имени свойства объекта приведут к отказу теста
  }
  //Общедоступный метод
  getPrice(productId){
    const desiredProduct= DB.getProduct(productId);
    finalPrice = this.calculateVATAdd(desiredProduct.price).finalPrice;
  }
}


it("White-box test: When the internal methods get 0 vat, it return 0 response", async () => {
    //Система не должна позволять пользователям рассчитывать показатель VAT, она лишь должна выводить итоговую стоимость. Но мы, несмотря на это, тестируем тут внутренние механизмы класса
    expect(new ProductService().calculateVATAdd(0).finalPrice).to.equal(0);
});

▍5. Выбирайте подходящие объекты-дублёры: избегайте моков, отдавая предпочтение стабам и шпионам

Последствия отступления от рекомендаций

При любом рефакторинге кода придётся искать все моки, подвергая рефакторингу и их код. В результате поддержка тестов превратится в тяжкое бремя, делая их врагами разработчика, а не его друзьями.

Неправильный подход

В этом примере показан мок-объект, ориентированный на тестирование внутренних механизмов приложения.

it("When a valid product is about to be deleted, ensure data access DAL was called once, with the right product and right config", async () => {
    //Предположим, что мы уже добавили товар
    const dataAccessMock = sinon.mock(DAL);
    //Это плохо, так как мы тут тестируем внутренние механизмы системы
    dataAccessMock.expects("deleteProduct").once().withArgs(DBConfig, theProductWeJustAdded, true, false);
    new ProductService().deletePrice(theProductWeJustAdded);
    mock.verify();
  });

Правильный подход

Шпионы нацелены на испытание систем на соответствие требований к ним, но, в виде побочного эффекта, неизбежно затрагивают внутренние механизмы систем.

it("When a valid product is about to be deleted, ensure an email is sent", async () => {
    //Предположим, что мы уже добавили товар
    const spy = sinon.spy(Emailer.prototype, "sendEmail");
    new ProductService().deletePrice(theProductWeJustAdded);
    //Это нормальный подход. Мы имеем дело с внутренними механизмами системы? Да, но лишь в виде побочного эффекта испытания системы на соответствие техническим требованиям к ней (отправка электронного письма)
});

▍6. В ходе тестирования используйте реалистичные входные данные, не ограничиваясь чем-то вроде «foo»

Последствия отступления от рекомендаций

При тестировании проекта в ходе его разработки все тесты могут оказаться пройденными лишь в том случае, если при их проведении используются нереалистичные данные наподобие строк «foo». А вот в продакшне система даст сбой в ситуации, когда хакер передаст ей что-то вроде @3e2ddsf . ##’ 1 fdsfds . fds432 AAAA.

Неправильный подход

Система успешно проходит эти тесты лишь потому что в них используются нереальные данные.

const addProduct = (name, price) =>{
  const productNameRegexNoSpace = /^S*$/;//пробелы запрещены
  
  if(!productNameRegexNoSpace.test(name))
    return false;//Сюда мы, из-за нереалистичных входных данных, не доберёмся.

    
    //Тут будет какой-то код
    return true;
};

it("Wrong: When adding new product with valid properties, get successful confirmation", async () => {
    //Строка "Foo", используемая во всех тестах, не позволит проверить ситуацию, в которой возвращается false
    const addProductResult = addProduct("Foo", 5);
    expect(addProductResult).to.be.true;
    //Ненадёжный результат: операция завершается успешно лишь из-за того, что мы
    //не использовали в тесте длинные имена товаров с пробелами
});

Правильный подход

Здесь используются рандомизированные данные, похожие на настоящие.

it("Better: When adding new valid product, get successful confirmation", async () => {
    const addProductResult = addProduct(faker.commerce.productName(), faker.random.number());
    //Сгенерированы следующие входные данные: {'Sleek Cotton Computer',  85481}
    expect(addProductResult).to.be.true;
    //Тест не пройден, так как наши входные данные привели к срабатыванию механизма, нарушающего нормальную работу системы.

    //Мы нашли ошибку на этапе разработки, а не в продакшне!
});

▍7. Испытывайте системы с использованием множества комбинаций входных данных, применяя тестирование, основанное на проверке свойств

Последствия отступления от рекомендаций

Разработчик, неосознанно, выбирает такие тестовые данные, которые покрывают лишь те участки кода, которые работают правильно. К сожалению, это снижает эффективность тестирования как средства для обнаружения ошибок.

Правильный подход

Тестирование множества вариантов входных данных с использованием библиотеки mocha-testcheck.

require('mocha-testcheck').install();
const {expect} = require('chai');
const faker = require('faker');

describe('Product service', () => {
  describe('Adding new', () => {
    //это выполнится 100 раз с использованием различных случайных свойств
    check.it('Add new product with random yet valid properties, always successful',
      gen.int, gen.string, (id, name) => {
        expect(addNewProduct(id, name).status).to.equal('approved');
      });
  })
});

▍8. Стремитесь к тому, чтобы код теста был бы самодостаточным, минимизируя внешние вспомогательные средства и абстракции

Последствия отступления от рекомендаций

Вы обнаружили, что в ваших тестах применяется 4 вспомогательных модуля, 2 из которых унаследованы от базовых утилит, много кода для настройки тестовой среды и несколько хуков? Принимайте поздравления! Теперь вам надо будет поддерживать ещё один непростой проект, а если всё и дальше будет продолжаться в том же духе, то вы скоро начнёте писать тесты для тестов.

Неправильный подход

Взгляните на эту интересную и запутанную структуру. Ясен ли вам смысл происходящего без обращения к коду внешних зависимостей?

test("When getting orders report, get the existing orders", () => {
    const queryObject = QueryHelpers.getQueryObject(config.DBInstanceURL);
    const reportConfiguration = ReportHelpers.getReportConfig();//Что это за конфигурация? Из кода теста это неясно
    userHelpers.prepareQueryPermissions(reportConfiguration);//Что здесь происходит? Без внешних источников этого не понять
    const result = queryObject.query(reportConfiguration);
    assertThatReportIsValid();//Снова неясный момент, опять придётся уходить из кода теста и читать об этом где-то ещё
    expect(result).to.be.an('array').that.does.include({id:1, productd:2, orderStatus:"approved"});
    //откуда мы знаем о существовании этого заказа? придётся покинуть код теста и это выяснить
})

Правильный подход

Вот пример теста, понять который можно без обращения к стороннему коду.

it("When getting orders report, get the existing orders", () => {
    //Хочется надеяться, что код этого текста понятен сам по себе
    const orderWeJustAdded = ordersTestHelpers.addRandomNewOrder();
    const queryObject = newQueryObject(config.DBInstanceURL, queryOptions.deep, useCache:false);
    const result = queryObject.query(config.adminUserToken, reports.orders, pageSize:200);
    expect(result).to.be.an('array').that.does.include(orderWeJustAdded);
})

▍9. Избегайте использования глобальных настроек и заранее подготовленных данных: пусть каждый тест пользуется собственными данными

Последствия отступления от рекомендаций

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

Неправильный подход

Тесты в этом примере не являются независимыми. Они полагаются на некий глобальный хук, пользуясь общей базой данных.

before(() => {
  //добавляем сведения об объектах и администраторах в БД. Где находятся данные? Где-то снаружи, например - в некоем json-файле.

  await DB.AddSeedDataFromJson('seed.json');
});
it("When updating site name, get successful confirmation", async () => {
  //Мне известно, что объект, называемый "Portal", существует, так как я видел его в файле с начальными данными
  const siteToUpdate = await SiteService.getSiteByName("Portal");
  const updateNameResult = await SiteService.changeName(siteToUpdate, "newName");
  expect(updateNameResult).to.be(true);
});
it("When querying by site name, get the right site", async () => {
  //Мне известно, что объект, называемый "Portal", существует, так как я видел его в файле с начальными данными
  const siteToCheck = await SiteService.getSiteByName("Portal");
  expect(siteToCheck.name).to.be.equal("Portal"); //Сбой! Предыдущий тест поменял название объекта :[
});

Правильный подход

Мы можем не покидать пределы теста, организовав всё так, чтобы каждый тест работал бы с собственным набором данных.

it("When updating site name, get successful confirmation", async () => {
  //тест добавляет в базу новые записи и работает только с ними
  const siteUnderTest = await SiteService.addSite({
    name: "siteForUpdateTest"
  });
  const updateNameResult = await SiteService.changeName(siteUnderTest, "newName");
  expect(updateNameResult).to.be(true);
});

▍10. Не перехватывайте в тесте исключения, возникающие в коде. Обрабатывайте их с помощью конструкции expect

Последствия отступления от рекомендаций

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

Неправильный подход

Вот длинный код теста, в котором сделана попытка проверки выдачи кодом исключений с помощью конструкции try-catch.

it("When no product name, it throws error 400", async() => {
let errorWeExceptFor = null;
try {
  const result = await addNewProduct({name:'nest'});} 
catch (error) {
  expect(error.code).to.equal('InvalidInput');
  errorWeExceptFor = error;
}
expect(errorWeExceptFor).not.to.be.null;
//Если это утверждение не выполнится, то в отчёте о проведении теста будет сказано 
//лишь о том, что некое значение равняется null, и ни слова о выброшенном исключении
});

Правильный подход

Вот как использование конструкции expect позволяет написать тест, отчёт которого будет понятен даже специалисту, далёкому от работы с кодом приложения.

it.only("When no product name, it throws error 400", async() => {
  expect(addNewProduct)).to.eventually.throw(AppError).with.property('code', "InvalidInput");
});

▍11. Назначайте тестам теги, указывающие на их особенности

Последствия отступления от рекомендаций

Если представить себе, что каждый раз, когда разработчики вносят небольшое изменение в код, выполняется куча тестов, в ходе которых производятся десятки запросов к базе данных, то окажется, что проводиться это тестирование будет крайне медленно. В результате разработчики постараются от таких тестов избавиться.

Правильный подход

Тег #cold-test позволяет системе запуска тестов отобрать только те из них, на выполнение которых много времени не требуется. В данном случае такой тег указывает на то, что тест работает быстро и не пользуется подсистемой ввода-вывода, а значит, вызывать его можно очень часто — буквально в процессе ввода кода разработчиком.

//этот тест очень быстр (в частности, не взаимодействует с БД), поэтому мы назначаем ему
//соответствующий тег, что позволяет пользователю или системе выполнения тестов
//вызывать его часто
describe('Order service', function() {
  describe('Add new order #cold-test #sanity', function() {
    it('Scenario - no currency was supplied. Expectation - Use the default currency #sanity', function() {
      //какой-то код
    });
  });
});

▍12. Не забывайте о других правилах подготовки качественных тестов

Последствия отступления от рекомендаций

Разработка через тестирование — это техника разработки ПО, которая вобрала в себя многие годы опыта. Неразумно полностью от всего этого отказываться.

Раздел 2. Типы тестов

▍13. Расширьте набор используемых вами методик тестирования, выйдя за пределы модульных тестов и пирамиды тестов

Последствия отступления от рекомендаций

Если разработчик не будет присматриваться к современным методикам тестирования — он может пропустить нечто весьма эффективное (вроде фаззинга), почти мгновенно оправдывающее усилия на его внедрение.

Правильный подход

Здесь мы предложим вам пару полезных публикаций. Вот материал о тестировании микросервисов. Вот видео о том, что, в сфере Node.js, можно увидеть за границами модульных тестов.

▍14. Возможно, вам стоит обратить внимание на компонентное тестирование

Последствия отступления от рекомендаций

Пользуясь исключительно модульными тестами, можно, потратив долгие дни на их написание, обнаружить, что код покрыт тестами лишь процентов на 20.

Правильный подход

Вот библиотека supertest, которая позволяет тестировать API, созданные с использованием Express, делая это быстро и покрывая тестами множество уровней абстракции.

Тестирование Node.js-проектов. Часть 1. Анатомия тестов и типы тестов - 3

Тестирование API, разработанных средствами Express

▍15. Для того чтобы быть уверенным в том, что новые релизы проекта не нарушают работу API, используйте шаблон Consumer-Driven Contracts

Последствия отступления от рекомендаций

Альтернативами вышеописанного подхода являются изнурительное ручное тестирование или страх развёртывания новой версии сервера.

Правильный подход

Тестирование Node.js-проектов. Часть 1. Анатомия тестов и типы тестов - 4

Шаблон Consumer-Driven Contracts

На этапе разработки микросервис А, через брокера, сообщает микросервису B о том, чего он от него ждёт. Микросервис B это учитывает и система без проблем работает в продакшне.

▍16. Тестируйте промежуточное ПО в изоляции

Последствия отступления от рекомендаций

Ошибка в промежуточном программном обеспечении Express означает неправильную обработку всех или большинства запросов.

Правильный подход

Вот пример тестирования промежуточного ПО в изоляции без выполнения реальных сетевых вызовов и без задействования всего Express-сервера.

//Промежуточное ПО, которое мы хотим протестировать
const unitUnderTest = require('./middleware')
const httpMocks = require('node-mocks-http');
//Тут используется Jest, то же самое в Mocha реализуется с помощью describe() и it()
test('A request without authentication header, should return http status 403', () => {
  const request = httpMocks.createRequest({
    method: 'GET',
    url: '/user/42',
    headers: {
      authentication: ''
    }
  });
  const response = httpMocks.createResponse();
  unitUnderTest(request, response);
  expect(response.statusCode).toBe(403);
});

▍17. Исследуйте код и выполняйте рефакторинг с использованием статических анализаторов

Последствия отступления от рекомендаций

В продуктах, код которых отличается низким качеством, всегда есть ошибки. Такой код может отличаться низкой производительностью. Эти проблемы не исправить ни за счёт использования новейших библиотек, ни за счёт наличия у таких продуктов уникальных возможностей.

Правильный подход

Вот как выглядит работа с коммерческим анализатором кода Code Climate.

Тестирование Node.js-проектов. Часть 1. Анатомия тестов и типы тестов - 5

Работа с Code Climate

▍18. Проверьте готовность проекта к хаосу, который может царить в среде Node.js

Последствия отступления от рекомендаций

От хаотических ошибок никто не застрахован, поэтому, не учитывая возможность их возникновения, вы рискуете столкнуться с ними в самый неожиданный момент.

Правильный подход

Вот страница npm-пакета chaos-monkey, который позволяет проверять приложения на устойчивость к самым разным странностям среды Node.js.

Тестирование Node.js-проектов. Часть 1. Анатомия тестов и типы тестов - 6

Пакет chaos-monkey

Итоги

Сегодня мы привели вашему вниманию почти два десятка советов, касающихся тестирования Node.js-проектов. В частности, мы поговорили об анатомии тестов и о типах тестов. В следующий раз поговорим об оценке эффективности тестов и об анализе качества кода.

Уважаемые читатели! Используете ли вы принципы хаос-инженерии при тестировании своих проектов?

Автор: ru_vds

Источник

Информация

Обсуждаемое

Рекомендуем

Тестирование Node.js-проектов. Часть 1. Анатомия тестов и типы тестов

▍0. Золотое правило: тесты должны быть очень простыми и понятными

Раздел 1. Анатомия тестов

▍1. Проектируйте тесты так, чтобы отчёт сообщал бы о том, что тестируется, по какому сценарию, и о том, чего ждут от тестов

Рекомендации

Последствия отступления от рекомендаций

Правильный подход

Правильный подход

▍2. Описывайте то, чего ожидают от тестов, на языке продукта: используйте утверждения в стиле BDD

Рекомендации

Последствия отступления от рекомендаций

Неправильный подход

Правильный подход

▍3. Выполняйте линтинг кода тестов с помощью специальных плагинов

Рекомендации

Последствия отступления от рекомендаций

Неправильный подход

▍4. Придерживайтесь метода «чёрного ящика» — тестируйте только общедоступные методы

Рекомендации

Последствия отступления от рекомендаций

Неправильный подход

▍5. Выбирайте подходящие объекты-дублёры: избегайте моков, отдавая предпочтение стабам и шпионам

Рекомендации

Последствия отступления от рекомендаций

Неправильный подход

Правильный подход

▍6. В ходе тестирования используйте реалистичные входные данные, не ограничиваясь чем-то вроде «foo»

Рекомендации

Последствия отступления от рекомендаций

Неправильный подход

Правильный подход

▍7. Испытывайте системы с использованием множества комбинаций входных данных, применяя тестирование, основанное на проверке свойств

Рекомендации

Последствия отступления от рекомендаций

Правильный подход

▍8. Стремитесь к тому, чтобы код теста был бы самодостаточным, минимизируя внешние вспомогательные средства и абстракции

Рекомендации

Последствия отступления от рекомендаций

Неправильный подход

Правильный подход

▍9. Избегайте использования глобальных настроек и заранее подготовленных данных: пусть каждый тест пользуется собственными данными

Рекомендации

Последствия отступления от рекомендаций

Неправильный подход

Правильный подход

▍10. Не перехватывайте в тесте исключения, возникающие в коде. Обрабатывайте их с помощью конструкции expect

Рекомендации

Последствия отступления от рекомендаций

Неправильный подход

Правильный подход

▍11. Назначайте тестам теги, указывающие на их особенности

Рекомендации

Последствия отступления от рекомендаций

Правильный подход

▍12. Не забывайте о других правилах подготовки качественных тестов

Рекомендации

Последствия отступления от рекомендаций

Раздел 2. Типы тестов

▍13. Расширьте набор используемых вами методик тестирования, выйдя за пределы модульных тестов и пирамиды тестов

Рекомендации

Последствия отступления от рекомендаций

Правильный подход

▍14. Возможно, вам стоит обратить внимание на компонентное тестирование

Рекомендации

Последствия отступления от рекомендаций

Правильный подход

▍15. Для того чтобы быть уверенным в том, что новые релизы проекта не нарушают работу API, используйте шаблон Consumer-Driven Contracts

Рекомендации

Последствия отступления от рекомендаций

Правильный подход

▍16. Тестируйте промежуточное ПО в изоляции

Рекомендации

Последствия отступления от рекомендаций

Правильный подход

▍17. Исследуйте код и выполняйте рефакторинг с использованием статических анализаторов

Рекомендации

Последствия отступления от рекомендаций