Как дополнение к статье, так совпало, что в день публикации провел вебинар на ту же тему, по ссылке видео с него.
Кстати, автор и евангелист Spec By Example, Гойко Аджич, будет вести тренинг в Мск этой весной.
На эту тему в фейсбуке недавно проскакивала картинка =) а вообще мероприятия, инструменты и конференция звучат конечно лучше, извиняюсь за подобный сленг
Ну собственно этот пост и готовился как обзорный — просто чтобы начать рассказывать про DevOps как явление. Дальше уже буду делать посты и эвенты про конкретные тулы и приемы. В частности на конфе AgileDays у меня мастер-класс по Chef.
Среди российских компаний могу сказать, что HeadHunter идет по пути DevOps. Кроме того, наша компания внедряет такой подходе в ряде компаний. В планах перевести статьи о том, как построили DevOps во Flickr и ряде других компаний.
Возникает стойкое ощущение, что вы не прочувствовали TDD, потому что оно является следующим этапом программирования по контракту и позволяет писать только тот код, который нужен на данном этапе с точки зрения требований. Именно отсюда и возникает эволюционный дизайн. Опять же, важным этапом TDD является рефакторинг, одной из задач которого и является приведение архитектуры к стройному виду.
Вообще, с TDD такая же история как с Agile вцелом, каждый понимает его по своему с налета, не пробую посмотреть по сторонам и поучиться у других. Жаль(
Подход «тесты вперед» всегда позволяет писать правильный код и при этом только минимальное количество. Эволюционный и адаптивный дизайн тоже возникает только при TDD. Детальная документация кода возникает когда тестов много — это раз, и когда в тестах проверяется только нужное — это два. Это тоже возможно только когда они появляются в ходе TDD.
И да, TDD это не юнит-тестирование, это дизайн кода через тесты.
Суть данного поста не сводилась к описанию пользы от TDD, я только хотел передать мысль о том, как его внедрять. Сами преимущества описаны по ссылке.
Ключевые из них, на мой взгляд:
Когда пишешь тест в начале, думаешь о том, как написать правильный код
Первый вариант более правильный, имхо, так как если что, неактуальный тест проще удалить и написать заново, чем пытаться что-то разобрать в связке unit-тестов. По поводу второго варианта — есть возможность задавать данные не из внешнего файла, а из кода; наглядный пример — TestFabric в TestNG для Java. Думаю что-то похожее есть, я думаю, и для других фреймворков/языков.
P.S.: мое имхо, если unit-тест, особенно написанный в процессе TDD, работает с файлами, то это уже не unit-тест, а интеграционный. По-крайне мере я это видел в ряде литературы.
Кстати, на правах пиара — сейчас развивается подобное русскоязычное сообщество Russian Software Craftsmanship Community. Мы проводим два типа встреч — XP Battle (ежемесячные встречи с целью изучения одной из инженерных практик) и Code&Coffee (утренние встречи с целью покодить в свободной обстановке). Так же зову всех в группу на FaceBook. В планах есть и CodingDojo, и StudyGroup для изучения книг и многое другое.
фейлят конкретные фреймворки типа скрама, нарушая его правила. что же касается agile — принципы нарушаются так же с легкостью, особенно про людей и про документацию.
Кстати, автор и евангелист Spec By Example, Гойко Аджич, будет вести тренинг в Мск этой весной.
И да, ТДД я открыл достаточно давно, но это так, к слову)
Вообще, с TDD такая же история как с Agile вцелом, каждый понимает его по своему с налета, не пробую посмотреть по сторонам и поучиться у других. Жаль(
И да, TDD это не юнит-тестирование, это дизайн кода через тесты.
Ключевые из них, на мой взгляд:
P.S.: мое имхо, если unit-тест, особенно написанный в процессе TDD, работает с файлами, то это уже не unit-тест, а интеграционный. По-крайне мере я это видел в ряде литературы.
P.P.S.: за ссылку спасибо, интересно!