Продолжаем цикл «Календарь тестировщика». В этот раз ответим на вопросы: зачем тестировщику читать книги? Что лучше книг? Есть миллион статей про это. У тестировщиков Контура Виталия Рощупкина и Кати Пальчиковой есть ещё одно мнение. И проверенные ими способы: как найти время, как мотивировать себя и коллег.
Так выглядела библиотека тестеров Контура в 2017
import org.junit.jupiter.api.extension.*;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.util.StopWatch;
public class TimingExtension implements BeforeTestExecutionCallback, AfterTestExecutionCallback, BeforeAllCallback, AfterAllCallback {
private static final Logger log = LoggerFactory.getLogger("result");
private StopWatch stopWatch;
@Override
public void beforeAll(ExtensionContext ctx) {
stopWatch = new StopWatch("Execution time of " + ctx.getRequiredTestClass().getSimpleName());
}
@Override
public void beforeTestExecution(ExtensionContext ctx) {
log.info("Start stopWatch");
stopWatch.start(ctx.getDisplayName());
}
@Override
public void afterTestExecution(ExtensionContext ctx) {
stopWatch.stop();
log.info("stop stopWatch");
}
@Override
public void afterAll(ExtensionContext ctx) {
log.info('\n' + stopWatch.prettyPrint() + '\n');
}
}
Все началось более 2-х лет тому назад, и я перешел на 4-й курс специальности "Бизнес-информатика" Томского Государственного Университета Систем Управления и Радиоэлектроники (ТУСУР). До окончания ВУЗА оставалась не много времени, и перспектива написания диплома уже маячила перед глазами. Мысль о покупке готовой работы не рассматривалась. Хотелось реально что-то сделать самому. Вариантов тем дипломных проектов рассматривалось много: и проекты конфигураций для автоматизации производственных нужд компании и проект внедрения Документооборота своими силами на 3 территориальные единицы и более 500 активных пользователей и внедрение ЭДО. Короче много всего что было в голове, но ничего из этого не вдохновляло. А это было главное.
Меня не интересуют истории, которые оставляют зрителя безразличным. Я хочу, чтобы выходя из кинотеатра человек думал: «Черт возьми, мне нужно выпить». (с) Киллиан Мёрфи
Так, что это значит Кино и BDD?! Добро пожаловать под кат.
Здравствуйте, коллеги. Напоминаем, что не так давно у нас вышли две классные классические книги о хакинге и анализе вредоносного ПО. А также на подходе великолепная книга о дистрибутиве Kali Linux. Тем не менее, мы по-прежнему полагаем, что тема компьютерной безопасности у нас охвачена не полностью и хотели бы поинтересоваться вашим мнением о книге Юрия Диогенеса и Эрдала Озкая о взаимодействии Red Team и Blue Team при проверке информационной безопасности на предприятии.
В этом посте я расскажу о том, как я писал консольную программу на языке Go для выгрузки данных из БД в файлы, стремясь покрыть весь код тестами на 100%. Начну с описания, зачем мне нужна была это программа. Продолжу описанием первых трудностей, некоторые из которых вызваны особенностями языка Go. Дальше немного упомяну сборку на Travis CI, а затем расскажу о том, как я писал тесты, пытаясь покрыть код на 100%. Немного затрону тестирование работы с БД и файловой системой. А в заключении скажу о том, к чему приводит стремление максимально покрыть код тестами и о чём говорит этот показатель. Материал я сопровожу ссылками как на документацию, так и на примеры коммитов из своего проекта.
Несмотря на то, что технологии модульного тестирования существуют уже 30 лет (в 1989 году Кент Бек написал статью “Simple Smalltalk Testing: With Patterns”), тем не менее не все программисты владеют этой технологией и не все компании сделали автоматическое тестирование частью своей корпоративной культуры. Даже несмотря на очевидные преимущества автоматического тестирования, все равно поведенческое сопротивление достаточно сильное. Кто пробовал внедрять автоматические тесты, тот знает, что всегда найдется какая-то причина, почему это не удалось сделать.
Из моего личного опыта внедрения методов надежного программирования в своей компании, в компаниях, которые я консультировал, общения на конференциях, а также из публично доступных источников, я сформулировал типичные возражения и сопротивления, которые препятствуют внедрению культуры автоматического тестирования.
Все возражения я сгруппировал в пирамиду надежного программирования, которая включает четыре уровня:
