о категоризации тестов

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

что это такое
суть в том, что перед каждым тестом мы на него вешаем атрибут с тегом (пример выполнен на языке С# с фреймворком запуска Gallio MBUnit).

        [Test]
        [Category("Contact-List")]
        [Category("Presence")]
        [Category("Chat")]
        public void  CheckUserStatusInContactListTest()
        {

                   //...

        }

Получилась примерно такая картинка.

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

коротко о впечатлениях:
1. стало реально удобнее. чисто эстетически приятнее работать с тестами, когда они разбиты по тегам.
2. стало быстрее, за счет того, что перед тем, как бездумно жмякать на кнопки запустить все, ты подумал, а что реально тебе нужно, и что можно запустить на всякий случай, а что нахер не надо. так вот, третья группа реально была якорем. много тестов, часть из которых еще и проходила не с первого раза. в результате тратилось время на прохождение, потом на анализ результатов, потом на перезапуск.

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

Отзыв на книгу Р.Мартин "Идеальный программист. Как стать профессионалом в области разработки ПО"

Купил книгу на сайте издательства Питер в электронном виде. Насколько я понял, в печать ее пока не сдали. Но это однозначный мастрид, если вы работаете в области IT.
Полезность: высокая.
Легко ли читать: легко.

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

Тем не менее, не везде лично я мнение автора разделяю. К примеру, в главе про оценку я с автором не согласен. Закон больших чисел, который он приводит в качестве примера для более точной оценки, противоречит закону Паркинсона про то, что работа занимает все отведенное ей время. Тут я, скорее, соглашусь с дядькой Голдраттом, который в "Критической цепи" довольно детально объяснил, почему подстраховка в оценке задач является причиной того, что только 30% проектов сдаются в срок.

Где-то мысли автора пересекаются с проповедями Макса Дорофеева на тему того, что если делать качественно, то получится и в срок, и дешево, и со всеми плюшками.

Особенно в душу запала фраза "Выберите методы, с которыми вы работаете в кризисных ситуациях. А потом начните использовать их постоянно". Не знаю, почему, но это прям за живое задело. А вообще, в книге много полезного. Там и про то, как говорить "нет", что очень важно в повседневной работе программиста. Там и про то, как подходить к планированию. И очень очень много про командную работу.

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

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