Комментарии 57
К сожалению научиться хорошо программировать намного легче чем научиться программировать без ошибок или использовать автоматизированые тесты.
Говорю на своем опыте.
Да и тесты — они частно нафиг не нужны. Думаю отладить маленькие функции — проблемы нет.
Года три назад к нам в офис приезжали tauSDL
Model Driven Development of Complex Systems and Services
Суть проста — собираете каркас програмы на SDL диаграме, разбавляете Скодом
И получаете механизм на конечных автоматах…
IDE строит дерево возможных использованией, а потом полурандомно начинает туда сигналы и пакеты кидать.
Все ждет свихнется программа или нет.
В общем на этом тау летают боинги и лифты ходят :)
И мы тоже. За два года ниодного бага, ниодной проблемы.
Все были ВЫРВАНЫ из кода роботом во время симуляции
Говорю на своем опыте.
Да и тесты — они частно нафиг не нужны. Думаю отладить маленькие функции — проблемы нет.
Года три назад к нам в офис приезжали tauSDL
Model Driven Development of Complex Systems and Services
Суть проста — собираете каркас програмы на SDL диаграме, разбавляете Скодом
И получаете механизм на конечных автоматах…
IDE строит дерево возможных использованией, а потом полурандомно начинает туда сигналы и пакеты кидать.
Все ждет свихнется программа или нет.
В общем на этом тау летают боинги и лифты ходят :)
И мы тоже. За два года ниодного бага, ниодной проблемы.
Все были ВЫРВАНЫ из кода роботом во время симуляции
ИМХО, тестирование хотя и полезная вещь, но для более успешного создания безбаговой программы важнее использовать хорошую архитектуру. Хорошая архитектура, в моем понимании, подразумевает высокую степень инкапсуляции и низкую степень сцепления между компонентами. Тогда, как правило, отладив один компонент, можно про него «забыть» до лучших времен, и вероятность того, что он «сломается», практически нулевая.
Кроме того, есть еще два возражения, благодаря которому у меня тестирование не прижилось.
1) Практическая невозможность тестировать пользовательские интерфейсы.
2) Сильное понижение скорости разработки за счет написания тестов для нетривиальных компонент — которые работают с выводом, только в контексте системы, используют ввод пользователя и переменные сервера… В результате, у меня есть только 2 или 3 компонента, которые могут быть эффективно оттестированны — один из них — это «слой» между программой и БД.
Ну, и еще о философском значении тестирования. Нас учили, что существуют несколько подходов к программированию — один из них — программирование как программная инженерия. Программная инженерия подразумевает, что есть архитектор и много-много кодеров, почти как при создании реального здания. Практика тестирования, хочу заметить, развивалось именно в рамках этого подхода. Она там практически необходима для того, чтобы контролировать «кодеров». Это не значит, что она не полезна в рамках других подходов. Но это значит, что существуют и другие подходы, например, программирование, как искусство создания кода. Понятного кода, который практически не нуждается в тестировании, и понятной архитектуры.
Кроме того, есть еще два возражения, благодаря которому у меня тестирование не прижилось.
1) Практическая невозможность тестировать пользовательские интерфейсы.
2) Сильное понижение скорости разработки за счет написания тестов для нетривиальных компонент — которые работают с выводом, только в контексте системы, используют ввод пользователя и переменные сервера… В результате, у меня есть только 2 или 3 компонента, которые могут быть эффективно оттестированны — один из них — это «слой» между программой и БД.
Ну, и еще о философском значении тестирования. Нас учили, что существуют несколько подходов к программированию — один из них — программирование как программная инженерия. Программная инженерия подразумевает, что есть архитектор и много-много кодеров, почти как при создании реального здания. Практика тестирования, хочу заметить, развивалось именно в рамках этого подхода. Она там практически необходима для того, чтобы контролировать «кодеров». Это не значит, что она не полезна в рамках других подходов. Но это значит, что существуют и другие подходы, например, программирование, как искусство создания кода. Понятного кода, который практически не нуждается в тестировании, и понятной архитектуры.
Хорошую архитектуру очень важно использовать, но это ни уменьшает значения _интеграционного_ тестирования. Трое достаточно шустрых программиста способны разнести любую архитектуру очень быстро, ContinuesIntegration и UnitTest в том числе, позволяют следить, за тем чтобы этого не случилось. Также следить за этим помогают все практики направленные collaborations.
По поводу возражений, соглашусь, всегда нужно думать что собираешься тестировать.
Последнюю мысль не понял.
По поводу возражений, соглашусь, всегда нужно думать что собираешься тестировать.
Последнюю мысль не понял.
Прошу прощения, не сразу понял, что имелось ввиду под ContinuesIntegration.
Фактически, постоянно использую именно только эту практику. С юнит-тестами, как уже писал, не сложилось, но, возможно, у меня просто не было ситуаций с 3 шустрыми программистами. В данном случае меня скорее спасают интерфейсы и соглашения. Выполняй — и все работать будет.
Фактически, постоянно использую именно только эту практику. С юнит-тестами, как уже писал, не сложилось, но, возможно, у меня просто не было ситуаций с 3 шустрыми программистами. В данном случае меня скорее спасают интерфейсы и соглашения. Выполняй — и все работать будет.
при правильной архитектуре, проблем с подцепкой тестов не должно возникать., на то она и _правильная_. тем более если у вас низкий уровень связанности, тогда компоненты тестировать и вовсе плёвое дело. Проблемы возникают когда связанность большая.
>> 1) Практическая невозможность тестировать пользовательские интерфейсы.
не обязательно покрывать тестами всё приложение, главное бизнес логику тестить.
>> 1) Практическая невозможность тестировать пользовательские интерфейсы.
не обязательно покрывать тестами всё приложение, главное бизнес логику тестить.
>> при правильной архитектуре, проблем с подцепкой тестов не должно возникать., на то она и _правильная_
Очень верное замечание, честно говоря, в исходном комментарии я немного слукавил :)
Но на самом деле у меня часто возникают ситуации с довольно простой бизнес-логикой, которую практически не нужно тестировать (ой-ли, может правда написать юнит-тесты?), но с довольно сложным интерфейсом.
Характерную ситуацию можно описать так: ядро создает обьект с помощью фабрики, затем вызывается метод, который настраивает объект другой фабрики, выдающий HTML-код некоего элемента управления. Причем сам элемент управления не является неким статичным HTML-кодом — он как раз может и должен меняться (View в модели MVC). Фактически, этот код и является результатом выполнения функции. Вопрос — как это грамотно протестировать?
Очень верное замечание, честно говоря, в исходном комментарии я немного слукавил :)
Но на самом деле у меня часто возникают ситуации с довольно простой бизнес-логикой, которую практически не нужно тестировать (ой-ли, может правда написать юнит-тесты?), но с довольно сложным интерфейсом.
Характерную ситуацию можно описать так: ядро создает обьект с помощью фабрики, затем вызывается метод, который настраивает объект другой фабрики, выдающий HTML-код некоего элемента управления. Причем сам элемент управления не является неким статичным HTML-кодом — он как раз может и должен меняться (View в модели MVC). Фактически, этот код и является результатом выполнения функции. Вопрос — как это грамотно протестировать?
ты должен отдельно тестить, обект подготавливающий данные и отдельно вьюху. ты же сам писал о низкой степени связоности, разделяй и властвуй. падовая известные значения в оба объекта по отдельности, ты можешь знать что получится на выходе, другое дело если их пытаться тестировать скопом, так даже не узнаешь в каком звене цепочки произошёл сбой.
Что касается веб-интерфейсов, то вопрос решается Selenium RC например, и других много тулов.
Хотя я согласен, что не все нужно и можно протестировать, но все-таки подход «архитектор-кодеры» плохо срабатывает, т. к. невозможно ручками контролировать все аспекты системы.
Хотя я согласен, что не все нужно и можно протестировать, но все-таки подход «архитектор-кодеры» плохо срабатывает, т. к. невозможно ручками контролировать все аспекты системы.
А еще лучше использовать хорошую архитекту покрытую тестами. Более того, тесты могут косвенно влиять на саму архитектуру в дальнейшем (т. к. со временем вы будите заранее, либо писать тесты, либо думать о том, как покрывать тестами тот или иной компонент, что в свою очередь будет приводить к малому сцеплению между компонентами). К сожалению, или к счастью если вы занимаетесь проектом не один, и проект развивается, то компонентов которые бы остались в совершенно неизменном виде с момента их первоночального написания остается крайне мало, а проверять каждое изменение вручную в итоге выйдет дольше, кроме того на одной из проверок кто нибудь, что нибудь обязательно забудет предусмотреть.
Вобщем-то автор статьи указал на решение.
По второму вопросу, мне честно говоря сложно представить систему, в которой успешно можно оттестировать только 3 компонента (при условии, что самих компонентов в системе много больше), возможно вы что-то делали не так, либо делали ваши тесты слишком избыточными (что тоже зло, т. к. тесты становяться слишком хрупкими).
TDD, является частью XP и часто приминяется вместе с практиками Agile, что само по себе противоречит «архитектор и много-много кодеров», а динамитом, некто Нобель тоже сначала планировал деревья корчевать, да завалы разбирать.
1) Практическая невозможность тестировать пользовательские интерфейсы.
Вобщем-то автор статьи указал на решение.
По второму вопросу, мне честно говоря сложно представить систему, в которой успешно можно оттестировать только 3 компонента (при условии, что самих компонентов в системе много больше), возможно вы что-то делали не так, либо делали ваши тесты слишком избыточными (что тоже зло, т. к. тесты становяться слишком хрупкими).
TDD, является частью XP и часто приминяется вместе с практиками Agile, что само по себе противоречит «архитектор и много-много кодеров», а динамитом, некто Нобель тоже сначала планировал деревья корчевать, да завалы разбирать.
Но это значит, что существуют и другие подходы, например, программирование, как искусство создания кода. Понятного кода, который практически не нуждается в тестировании, и понятной архитектуры.Звучит красиво, но уж очень похоже на идельный мир, а проекты живут в мире реальном, где случаются глюки, люди ошибаются, а софту, если он хочет быть надежным софтом, лучше все же быть протестированным.
Вторично прошу прощения — не сразу разобрался, что подразумевается под словом ContinuesIntegration. По сути, использую только эту практику. От использования юнит-тестов спасает использование интерфейсов и соглашения. Собственно, это и подразумевалось под хорошей архитектурой.
Насчет частого изменения компонентов — с вашим замечанием согласен. Однако я работаю в такой ситуации, когда мои компоненты используются в разных системах, в том числе и устаревших. В результате, я использую нечто вроде принципов COM — один раз определенный интерфейс _никогда_ не меняется. Если нужно использовать что-то более сложное («апгрейдить» компонент), то пишется второй интерфейс.
Насчет частого изменения компонентов — с вашим замечанием согласен. Однако я работаю в такой ситуации, когда мои компоненты используются в разных системах, в том числе и устаревших. В результате, я использую нечто вроде принципов COM — один раз определенный интерфейс _никогда_ не меняется. Если нужно использовать что-то более сложное («апгрейдить» компонент), то пишется второй интерфейс.
Я всегда считал, что при использовании TDD получается (сама собой) лучшая архитектура, чем без него, т. к. «testable» код подразумевает низкую степень сцепления.
Автор, а почему Вы разговариваете на «ты» с Вашим читателем?
А в целом соглашусь. Вы правы. Единственное, что не понравилось — выражение «Самая лучшая статья про CI». Кто же это решил, что она самая лучшая? Лично Вы или же есть статистика голосования (которую можно глянуть)?
А в целом соглашусь. Вы правы. Единственное, что не понравилось — выражение «Самая лучшая статья про CI». Кто же это решил, что она самая лучшая? Лично Вы или же есть статистика голосования (которую можно глянуть)?
если один авторитетный специалист сказал что статья лучшая, то значит она лучшая. а вот какое бы там не было голосование, оно все равно останется необоснованым и необъективным. степень авторитетности и знаний специалиста — это уже отдельный вопрос и как правило он решается при тесном общении с человеком, желателько в единой с ним рабочей среде. лично я задумаюсь и приму к сведению мнение авторитетного для меня специалиста, и не обращу внимания вообще на какие бы то нибыло голосвания хоть на хабре или где-то еще…
+1. WIndows — лучшая операционная система :-D
На «ты», т. к. «Этот топик мой ответ на жалобу одного человека, что «баги достали».» — это письмо другу если хотите.
Про статью Фаулера — да, это мое мнение, что она лучшая по CI. Т. е. лучше написать было «По моему мнения это самая лучшая статься по CI»…
Про статью Фаулера — да, это мое мнение, что она лучшая по CI. Т. е. лучше написать было «По моему мнения это самая лучшая статься по CI»…
Кстати многие менеджеры просто советуют обращаться на ты что бы быть ближе к человеку, а так же психологи советуют.
Де-факто, тестирование, и гибкая разработка, нужна лишь программистам/компаниям, играющим по взрослому.
Теперь зададим себе вопрос: а что такое тест? По-сути, это некоторый код, который запускает другой код (в цикле, с разными параметрами конфигураций и т. д). Ловит исключения, регистрирует их.
Так вот у меня вопрос: много людей, которые не делают этого? Т. е. не пишут стартер для классов?
Теперь зададим себе вопрос: а что такое тест? По-сути, это некоторый код, который запускает другой код (в цикле, с разными параметрами конфигураций и т. д). Ловит исключения, регистрирует их.
Так вот у меня вопрос: много людей, которые не делают этого? Т. е. не пишут стартер для классов?
* ContinuesIntegration и UnitTests работают не только в отношении web applications и PHP — это о связи содержания с заголовком.
* Регрессионное тестирование и юнит тестирование — это разные вещи.
* UnitTest наиболее сильна, если ее применять в рамках TDD (Test Driven Development), иначе может иногда даже в пустую отнимать время. Как обычно, весьма сложно покрываемая юнит тестами область — пользовательские интерфейсы и даже упомянутый в статье selenium позволяет решить проблему только в небольшой части. Еще избавить код от непроверенных комитов позволяют такие практики как CodeReview и PairProgramming (вместе не применять :))
* о СontinuesIntegration имеет смысл говорить если у вас 3 и более разработчиков, одновременно комитящих код, в остальных случаях, если это не налаженная ранее система, то потеря времени.
* начиная всерьез внедрять эти практики, Вы уже начали думать о методологии :)
* Регрессионное тестирование и юнит тестирование — это разные вещи.
* UnitTest наиболее сильна, если ее применять в рамках TDD (Test Driven Development), иначе может иногда даже в пустую отнимать время. Как обычно, весьма сложно покрываемая юнит тестами область — пользовательские интерфейсы и даже упомянутый в статье selenium позволяет решить проблему только в небольшой части. Еще избавить код от непроверенных комитов позволяют такие практики как CodeReview и PairProgramming (вместе не применять :))
* о СontinuesIntegration имеет смысл говорить если у вас 3 и более разработчиков, одновременно комитящих код, в остальных случаях, если это не налаженная ранее система, то потеря времени.
* начиная всерьез внедрять эти практики, Вы уже начали думать о методологии :)
1. Конечно не только для web applications и PHP. Про связь названия и содержания не понял — разве есть несоответствие?
2. Почему разные. ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%B3%D1%80%D0%B5%D1%81%D1%81%D0%B8%D0%BE%D0%BD%D0%BD%D0%BE%D0%B5_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5
думаю, что запуская юнит тесты при каждой сборки мы как раз удостоверяемся что старые ошибки снова не возникли. А еще если синтегрнировать с Selenium RC то можно и на уровне интерфейсов проверять.
3. Возможно.
4.
5. Но методология без практик мертва. Поэтому я и советую сначала сконцентрироваться на практиках. Так никакой Scrum сам по себе не сделает код качественнее.
2. Почему разные. ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%B3%D1%80%D0%B5%D1%81%D1%81%D0%B8%D0%BE%D0%BD%D0%BD%D0%BE%D0%B5_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5
думаю, что запуская юнит тесты при каждой сборки мы как раз удостоверяемся что старые ошибки снова не возникли. А еще если синтегрнировать с Selenium RC то можно и на уровне интерфейсов проверять.
3. Возможно.
4.
5. Но методология без практик мертва. Поэтому я и советую сначала сконцентрироваться на практиках. Так никакой Scrum сам по себе не сделает код качественнее.
всё уже найдено… и всё хочется попробовать… но вот пробовать надо на живых примерах. А там сроки, делайны, которые не хочется срывать. Всё не пойдёт гладко. А заставить всех программистов самообучаться новым технологиям вне рабочего времени — смерти подобно…
Спасибо за ссылки, а что насчёт phpUnderControl?
Автор, web application — это веб-приложение. Учите русский, не надо мешать языки. Либо целиком на английском пишите.
А вэб-приложение — это чисто на русском чтоли?
Конечно. Толко не вЭб, а веб. Слова «веб» и «приложение» имеются в русском языке. Что вас смущает?
слово веб — в русском языке?
Любой язык — это динамическая структура, постоянно пополняющаяся новыми словами. Безусловно, слово «веб» есть в русском языке. Ведь такое явление, как веб, надо обозначать каким-то термином, верно?
но тогда почему Вэб — неправильное слово?:)
В любой поисковой системе введите по очереди оба слова и посмотрите на каком количестве страниц каждое из них присутствует. Так же обратите внимание какие источники используют тот или иной вариант написания. Думаю, у вас отпадут все вопросы.
по вашей логике, кол-во страниц на слово х*й и пи*да (в сумме) должно быть такое же, как и на слово ж*па, потому что их количество в мире равно =)
это я к тому, что не все измеряется кол-вом результатов выдачи поисковика.
это я к тому, что не все измеряется кол-вом результатов выдачи поисковика.
Вы сделали, как я предложил, или сразу ответ написали? Только честно. По слову «вэб» вообще Внешэкономбанк находится, а по «веб» — то о чем мы с вами говорим, причем этот вариант используется авторитетными источниками.
Вообще конечно здорово: я вам про русский язык, а вы мне про гениталии :-/ Предлагаю закончить дискуссию на эту тему, ее никому не интересно читать кроме нас с вами.
Вообще конечно здорово: я вам про русский язык, а вы мне про гениталии :-/ Предлагаю закончить дискуссию на эту тему, ее никому не интересно читать кроме нас с вами.
еще и долбоебы минусуют =)
по ссылкам сходил, мне понравилось:
Вэб-инвест Банк
www.web-***.ru/
таки слово web у некоторых читается как вэб =)
по ссылкам сходил, мне понравилось:
Вэб-инвест Банк
www.web-***.ru/
таки слово web у некоторых читается как вэб =)
eclipse с phpunit дружит?
вообще хотелось бы вменяймое сравнение simpletest vs phpunit для того чтобы иметь возможность сознательного выбора
вообще хотелось бы вменяймое сравнение simpletest vs phpunit для того чтобы иметь возможность сознательного выбора
НЛО прилетело и опубликовало эту надпись здесь
Держи, коллега :) piece-framework.com/projects/makegood
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Некоторые инженерные практики для улучшения качества web application на PHP