Анализ тестов — как выкидывать лишнее

 Анализ тестов — это выкидывание лишнего из вашего чек-листа. Работа из серии «сесть и подумать»:

• какие проверки можно объединить?

• какие и вовсе выкинуть?

Было бы здорово дать некий алгоритм, который поможет всегда и везде, но нет, увы. Универсальная фраза здесь только «сесть и ПОДУМАТЬ». А самое главное: «вместе с водой не выплеснуть ребенка». Убирайте тесты аккуратно, особенно в первые годы работы. Возможно, выкинутое было отнюдь не лишним...

Но общий принцип анализа примерно такой:

1. Объединить позитивные тесты.

2. Выкинуть одинаковые классы эквивалентности.

3. Не тестировать один функционал 10 раз: проверять его в одном месте, а в остальных лишь то, что он в принципе работает.

Рассмотрим каждый пункт по отдельности. 

Ссылка на Хабр

Я победила в конкурсе «Технотекст 2021» в разделе «Просто о сложном»!

 

Я тут внезапно узнала, что победила в конкурсе «Технотекст 2021» в разделе «Просто о сложном» со своей статьей «Что такое VCS (система контроля версий)».

Пруфы:

https://habr.com/ru/company/habr/blog/670398/

Youtube, тайминг 38:16:

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

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

 

Это приятно! 😊

Я ведь как раз и стараюсь писать просто о сложном, так что признание этого — прямо успех! Хотела поделиться ))))

UPD — а вот и подарочки)

Все ругают самописные тестовые фреймворки. А мы своим довольны

Ссылка на Хабр

Коллеги с соседнего проекта написали статью про один из наших тестовых фреймворков. Очень круто все описали!

О том, как развивались автотесты продукта Фактор, где сейчас этих автотестов тысячи. Да, это бывает по тысяче строк в одном файле, казалось бы «фи, скукота, я то думал, тысяча строк юнит-тестов». Но нет, мы пришли к DDT и тому, чтобы один раз написать фреймворк, а потом получать «один тест = одна строка во входном и выходном файле».

Ребята рассказали про заглушки внутри тестов, учет статуса задачи в JIRA и про другие примочки. Это круто, я когда-то хотела про каждую отдельный постик написать. А, может, еще и напишу, но уже сейчас можно посмотреть «а как у них это работает».

Может, даже идеи для ваших автотестов появятся. Потому что с JIRA мы круто сделали, я считаю. Прикиньте, тест вроде заскипан (падение игнорируется при прогоне), но, если вдруг заработал сам по себе, система сигнализирует об этом. А то бывает же, что делаешь другую задачу и тут, опа-опа, что-то еще починил ¯\_(ツ)_/¯

Так что приятного чтения!

См также:
Автотесты на уровне API для Java-приложений — про тесты на моем проекте
Больно пилить автотесты? Проси улучшать! — и как мы их улучшали

Деревня Упыри и другие тестовые данные

На хабре вышла статья от моих коллег — Данные бывают смешными (и вот примеры).

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

Обязательно прочитайте комменты, там вы найдете еще больше нетривиальных примеров!