Постараюсь выразить наш опыт, который относится к документированию, а также дать небольшой обзор того, как рефакторинг и TDD соотносятся с наличием в коде inline-комметариев, комментариев в стиле phpDocumentor и с наличием документации на проект вообще.
Добавил: PIXEL Дата: 2008-02-27 09:04:11 Количество просмотров: 1584 Рейтинг: 0.00
Существует неформальное правило: «Неважно как громко вы кричите или как часто ругаете программистов, неважно какой толщины розги, которыми вы их бъете, выважно чем и как вы им угрожаете. Важно только одно - программисты будут использовать какой-либо инструмент или процесс, только если они поверят, что эти инструменты или процессы облегчат их работу.» Конечно, это правило касается не только программистов. Поэтому важно доказать программистам, что модульное тестирование будет экономить их силы, нервы и поможет зарабатывать больше денег. Внедрить TDD насильно невозможно.
Добавил: PIXEL Дата: 2008-02-27 09:03:18 Количество просмотров: 1513 Рейтинг: 0.00
Разберем некоторые причины, почему программисты не пишут автоматизированные тесты. Конечно, это будет далеко не полный список. Хотелось лишь указать, что большинство отговорок связаны как правило с непониманием сути автоматизированного тестирования, незнания эффективных технологий тестирования, плохим дизайном тестируемого кода и т.д.
Добавил: PIXEL Дата: 2008-02-27 09:02:21 Количество просмотров: 1550 Рейтинг: 0.00
Разберем, какие преимущества дает использование автоматизированных тестов. Основная суть всего, что будет сказано ниже - это то, что тесты позволяют писать более качественный код, а также снижают риск появления ошибок в коде. Некоторые вещи могут показаться спорными, неочевидными, или же очень знакомыми.
Добавил: PIXEL Дата: 2008-02-26 10:14:56 Количество просмотров: 1581 Рейтинг: 0.00
Один из самых очевидных признаков загнивания проекта. Кратко описать идею можно так - требуется слишком много времени для выполнения теста. Когда вы разрабатываете приложение, то должны иметь возможность выполнять весь набор тестов (TestSuite) неограниченное количество раз и не должны ждать тесты слишком долго. Весь набор модульных тестов приложения (конечно, если приложение не слишком большое) должен исполняться не дольше 1-2 минут. А тесты на тот модуль, который вы разрабатываете в данный момент должны срабатывать вообще мгновенно.
Добавил: PIXEL Дата: 2008-02-26 10:14:14 Количество просмотров: 1460 Рейтинг: 0.00
Многие программисты, однажды попробовав работать в стиле TDD, сталкиваются с многочисленными проблемами и бросают тестирование. Они отмечают, что модульное тестирование усложняет процесс разработки, делает его слишком медленным и более трудоемким из-за возрастающего объема тестового кода, который слишком сложно поддерживать. Общаясь с такими разработчиками, мы заметили, что они все сталкиваются с похожими проблемами и делают одни и те же ошибки. Но, как правило, во всем они винят именно тесты.
Добавил: PIXEL Дата: 2008-02-26 10:13:18 Количество просмотров: 1545 Рейтинг: 0.00
Ни один программист не считает работу над некоторым фрагментом кода завершенной, не проверив перед этим его работоспособность. Однако, если вы тестируете свой код, это не означает, что у вас есть тесты.
Добавил: PIXEL Дата: 2008-02-26 10:12:09 Количество просмотров: 1496 Рейтинг: 0.00
Разработка через тестирование - процесс разработки программного обеспечения, который предусматривает написание и автоматизацию модульных тестов еще до момента написания соответствующих классов или модулей. Это гарантирует, что все обязанности любого элемента программного обеспечения определяются еще до того, как они будут закодированы.
Добавил: PIXEL Дата: 2008-02-26 10:10:59 Количество просмотров: 1591 Рейтинг: 0.00
В любом проекте существует набор объектов, которые требуются большому количеству клиентов. К таким можно отнести соединение с базой данных, объекты конфигурации, пользователь, система прав, запрос(request) или ответ(response) системы, логгер, кеш – этот список можно продолжать. Раз они требуются большому числу клиентов – значит, они должны быть как минимум легко доступны практически в любой точке приложения. Для приложения средних размеров этот список уже большой – все через конструктор не передашь. Кроме этого, иногда возникает необходимость в том, чтобы сменить, скажем, метод обработки ошибок, драйвер базы данных, механизм кеширования и т.д. Идеально, если наше приложение потребовало бы при этом минимальных модификаций, не затрагивая при этом кода, реализующего бизнес-логику.
Добавил: PIXEL Дата: 2008-02-21 08:54:09 Количество просмотров: 1546 Рейтинг: 0.00
