Англійська мова для написання тестів мутацій і описів тестів на основі властивостей

Вивчіть англійський словник для опису перевірки на мутації, перевірки на основі властивостей і інваріантів під час обговорення якості перевірки з вашою командою.

Тестування на мутації і тестування за допомогою властивостей є менш поширеними, ніж тестування на основі одиниць або інтеграції, отже, коли ви їх використовуєте у описі PR або обговоренні стратегії тестування, ваш словник повинен бути точним — ваш читач може не мати спільної ментальної моделі. Цей підручник містить англійською мовою чіткий опис цих методів, незалежно від того, чи ви представляєте їх команді або повідомляєте про результати.

Ключовий словник

** Тестування на мутації ** — метод, який вводить невеликі навмисні помилки (« мутанти ») у код і перевіряє, чи вловлює їх тестовий набір, використовується для вимірювання того, наскільки ефективними є тести насправді, а не лише того, скільки коду вони покривають. “Ми провели тестування мутацій на модулі розрахунків і виявили, що 30% мутантів вижили, що означає, що наші тести не вловили цих введених вад, незважаючи на 95% покриття лінії.”

** Мутант ** — одна навмисна зміна коду (наприклад, перетворення оператора порівняння або зміна константи), яку використовують для перевірки, чи помітив це набір тестів. “Один виживший мутант змінив >= на > в перевірці порогу знижки, і жоден тест не провалився - це справжній прогалину в нашому покритті.”

** Вбито / вижило ** — мутанта « вбито », якщо тест зазнав невдачі через нього (добре — тест виявив ваду); він « виживатиме », якщо всі тести все одно пройдуть успішно (погано — тестовий набір не виявив ваду). “87% мутантів було вбито, що є досить високим показником, але 13%, які вижили, варто розслідувати окремо.”

** Тестування за допомогою властивостей ** — це підхід до тестування, за якого ви вказуєте загальну властивість, яка завжди має бути вказаною (інвариант), а система тестування генерує багато випадкових вхідних даних, щоб спробувати знайти контрприклад, замість того, щоб тестувати фіксовану кількість прикладів. “Замість написання десяти прикладних тестових випадків для функції сортування, ми написали один тест, заснований на властивостях, який стверджує, що вивід завжди сортується і містить ті ж елементи, що і вхід, і дозволяє фрейму генерувати сотні випадкових вхідних даних.”

** Invariant ** — властивість, яка завжди має значення true незалежно від вхідних даних, навколо якої побудовано тести, засновані на властивостях. “Інвариант, який ми тестуємо, полягає в тому, що декодування закодованого значення завжди повертає початкове значення — це має бути так для будь-якого вводу, а не тільки для прикладів, про які ми подумали.”

Звичайні фрази

  • «Наше покриття лінії є високим, але тестування на мутації виявило кілька прогалин в тому, що наші тести насправді перевіряють»
  • «Цей мутант вижив, тому що жоден тест не стверджує повернення значення в цій гілці.»
  • «Ми написали тест, заснований на властивостях, замість перерахування кращих випадків вручну»
  • «Інвариант тут полягає в тому, що функція є ідемпотентною — застосування її двічі дає той же результат, що і застосування її один раз»
  • «Фреймворк знайшов контрприклад, який ми не розглядали: порожній рядок з лише пробілів.»

Приклади висловлювань

Звітування про результати перевірки на мутації у PR або квитку:

  • “Проведено тестування на мутації у модулі обчислення знижок: рівень мутації становить 78%. Вцілілі мутанти зосереджені в кращих випадках навколо нуля і негативних кількостей, що свідчить про те, що наші тести насправді не використовують ці шляхи, незважаючи на те, що вони перераховані як покриті. ”*

Пояснення, чому було обрано тестування за допомогою властивостей, а не тестування за допомогою прикладів: “Замість написання окремих тестових випадків для кожного формату вводу, ми визначили інваріант, який аналіз і потім пересеріалізація повинні завжди давати еквівалентне значення, і дозволили базі даних, заснованій на властивостях, генерувати широкий спектр вхідних даних для безпосереднього тестування цього інваріанту.”

Опис вади, знайденої за допомогою цього методу:

  • “Тестування за допомогою властивостей знайшло контрприклад, який ми ніколи б не написали вручну: глибоко вкладений об’ єкт з круговою посиланням призвело до нескінченного повторення серіалізатора. Ми додали виправлення і регресійний тест для цього конкретного випадку.”*

Повідомлення про цю техніку команді, яка не знайома з нею: “Тестування на мутації працює по-іншому, ніж тестування на поширення — замість запитання « чи було виконано якийсь тест на цю лінію », він запитує « чи був би якийсь тест дійсно помічений, якщо ця лінія була б неправильною. » Це набагато сильніший сигнал того, чи виконують наші тести свою роботу. “

Професійні поради

  • При повідомленні результатів тестування на мутації, повідомте ** бал мутації ** як число, і описайте ** де зосереджені виживший мутанти ** - сирий відсоток сам по собі не є дієвим.
  • Поясніть тестування за допомогою властивостей, порівнюючи його безпосередньо з тестуванням за допомогою прикладів — більшість читачів вже розуміють тестування за допомогою прикладів, тому контраст швидко створює розуміння.
  • Використовуйте слово “інвариантний” навмисно — воно сигналізує “властивість, яка завжди існує”, що є більш точним, ніж “правило” або “умова”
  • Коли тестування за допомогою властивостей знаходить ваду, називайте вхід, що зазнав невдачі «контрприклад» — це стандартний термін і негайно повідомляє, що фреймворк спростував ваше припущення.
  • Якщо ви вперше вводите будь-яку техніку в команду, ведуть з конкретним прикладом помилки, яку вона вловила, що існуючі тести пропустили - абстрактні пояснення техніки набагато менш переконливі, ніж реальний результат.

Практичні вправи

  1. Напишіть речення, в якому буде вказано рівень мутацій і де зосереджені мутанти, що вижили.
  2. Напишіть речення, у якому буде вказано інваріант для гіпотетичної функції, у формі « X завжди має бути істинним незалежно від вхідних даних »
  3. Напишіть два речення, у яких ви представити співробітнику команди тестування за допомогою властивостей, порівнявши його з тестуванням за допомогою прикладів.

Наприклад, вивчення мовлення: визначення мовлення за допомогою тестів

Основні концепції тестування мутацій і тестування на основі властивостей — вивчення коду через навмисні помилки і стверджування очікуваної поведінки — можуть бути складними для чіткого вираження англійською, особливо якщо ваша рідна мова не дуже зосереджена на технічній точності. Це не просто про використання правильних слів; це про передачу наміру і будівництво спільного розуміння з колегами під час перегляду коду або командних обговорень. Поширеним камінням преткнення є надмірна залежність від жаргону, який може не звучати універсально. Наприклад, повторне зауваження «ми повинні збільшити охоплення» без подальшого пояснення може бути неправильно інтерпретовано як просто бажання більше тестів, а не зосередження на якості цих тестів.

Одна з ключових областей для поліпшення часто лежить в тому, як ми формуємо інварианти. Інвариант — це правило, яке * повинно * завжди бути істинним — подумайте про обмеження даних, бізнес-логіку або припущення про стан системи. При обговоренні інваріантів під час тестування, важливо вийти за рамки простого зауваження про те, що вони існують. Замість цього, націлюйтеся на такі фрази, як «Ми розробляємо тести, щоб забезпечити, що цей критичний інваріант залишається непорушеним», або «Давайте розглянемо, як тести, засновані на властивостях, можуть допомогти нам проактивно перевірити, що це припущення є істинним по всьому діапазону вхідних даних». Це демонструє, що ви думаєте про * чому * за стратегією тестування і її вплив на загальну надійність системи.

Іншою поширеною пасткою є представлення зворотнього зв’ язку в надто критичний спосіб. Фрази на кшталт «Цей тест нічого не охоплює» відразу ж є конфронтаційними. Більш конструктивним підходом було б: « Я бачу тут потенційний прогалину; чи можемо ми дослідити тестування мутацій, щоб конкретно націлити цю область коду? » або « Давайте розглянемо, чи тести, засновані на властивостях, можуть допомогти нам визначити крайні випадки, пов’ язані з цим інваріантом. » Пам’ ятайте, метою є співпраця — будівництво довіри до набору тестів і його здатності захищати від несподіваної поведінки.

Нарешті, пам’ ятайте про активний проти пасивного голосу при описі результатів тесту. Замість того, щоб сказати «Мутація була виявлена», часто краще сказати «Ми виявили мутацію, яка викликала невдалий тест», підкреслюючи * вашу * дію і внесок. Аналогічно, замість того, щоб вказати « Властивість зазнала невдачі », розгляньте « Тестування за допомогою властивостей виявило несподіваний сценарій ». Це змінює фокус з простого повідомлення про негативний результат на демонстрацію активного дослідження і розв’ язання проблем.

Поширені запитання

Про що ця стаття "Англійська мова для написання тестів мутацій і описів тестів на основі властивостей"?

Вивчіть англійський словник для опису перевірки на мутації, перевірки на основі властивостей і інваріантів під час обговорення якості перевірки з вашою командою.

Чи безкоштовна ця стаття?

Так. Усі статті на CoderSlingo, включно з цією, доступні безкоштовно без реєстрації.

Скільки часу займає читання "Англійська мова для написання тестів мутацій і описів тестів на основі властивостей"?

Приблизно 8 min.