К основному контенту

Тестируем свой код - книги в помощь

Полезные книжки для изучения TDD и unit-тестирования.
Тут только те, что сам читал (примечание: читаю я в основном на английском, не могу ничего сказать насчет русских переводов). Пошерстив чуток интернет, нашел отзывы и мнения и решил ими поделиться.

Классика: "Test Driven Development: By Example" Kent Beck
Отзыв на русское издание: "Экстремальное программирование. Разработка через тестирование",  все по делу написано.

Еще одна отличная книга The Art of Unit Testing Roy Osherove
Во время написания книги Рой работал в команде TypeMock. Он активно проводит тренинги на тему TDD. Сейчас правда перескочил с .Net на Ruby и в основном занят продвижением своей новой книги про лидерство в командах разработки. Но я отвлекся. Вот неплохой отзыв и еще один. Кстати, сам Рой дает свой список книг на тему разработки.

Если мы говорим о рефакторинге уже написанного кода, то тут вам в помощь Working Effectively with Legacy Code от Michael Feathers. Книгой очень удобно пользоваться, вторая ее глава  - это просто FAQ. То есть вы просто ищете свой вопрос и читаете ответ.

Chapter 6.  У меня нет времени, а менять нужно.
Chapter 7.  Изменения делаются постоянно
Chapter 8.  Как мне добавить новую фичу?
Chapter 9.  Я не могу добавить этот класс в тестовую сюиту
Chapter 10. Я не могу запускать этот метод в тестовой сюите
Chapter 11. Мне нужно сделать изменения. Какие методы я должен использовать
Chapter 12. Мне нужно сделать много изменений в одном месте. Должен ли я разорвать все зависимости во всех классах, которые используются там?
Chapter 13. Мне нужно сделать изменение, но я не знаю какие тесты писать
Chapter 14. Зависимости от библиотек меня убивают
Chapter 15. Мое приложение это сплошные API вызовы
Chapter 16. Я не до конца понимаю код для того, чтоб его менять
Chapter 17. Мое приложение не структурировано
Chapter 18. Мой тестовый код не ясен
Chapter 19. Мой проект не объектно-ориентированный. Как мне делать безопасные изменения?
Chapter 20. Этот класс очень большой, и я не хочу чтобы он становился больше
Chapter 21. Я изменяю один и тот же код в разных местах
Chapter 22. Мне нужно поменять метод-монстр, но я не могу написать тесты на него
Chapter 23. Как я узнаю, что я не ломаю ничего?
Chapter 24. Мы чуствуем себя хреново, дела не становятся лучше

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

Комментарии

Популярные сообщения из этого блога

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub.

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

Проверять работоспособность тестируемого объекта (system uder test - SUT) можно двумя способами: оценивая состояние объекта или его поведение.

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

Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT.

Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы.

Теперь подробнее.

Gerard Meszaros использует термин Test Double (дублер), как обозначение для объекта, который зам…

План "Б" или как прикольно провести субботний день

Всем привет.
Вчера состоялась конференция "План Б". Организаторами выступили ребята из Яндекса, за что им большое спасибо. Судя по приблизительным подсчетам в мероприятии участвовало около 200 человек.

Основной темой конференции было планирование, планирование всего: проектов, разработки, тестирования, дизайнеров и даже организации музыкального фестиваля.
Сначала думал написать отчет в обычном своем стиле: кто и что говорил, но почитав твиттер по #pbconf понял, что просто потеряю время :) Поэтому кому оооочень интересно узнать подробности следуйте за птичкой и вы все узнаете (тэг #pbconf попал в top-30 твиттера)
Здесь приведу лишь те вещи, которые мне запали в мозг
Роман Чернин о продуктовой разработке: "нет заказчика, нет требований, нет сроков -> как принимать решения? ответ: заводим себе Product Manager-а"
Оля Павлова (@op): "бойтесь иллюзии точной формулировки" "заказчик - ребенок, выдаем ему игрушку как можно чаще" "не забываем, …

Полезные ресурсы для молодых (и не только) тестировщиков

Уже 3 месяца провожу собеседования тестировщиков.
Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем то экзотическим и забавным.

Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.