Рефакторинг != оптимизация. А то, какая архитектура будет у вашего кода зависит целиком от вас, программистов. На Java и Ruby можно тоже встретить код, который проще выкинуть, чем пытаться рефакторить.
если посмотреть историю социальных сетей, то можно найти сведения о том, что первая появилась в Калифорнии в 1980-х годах, но не медленный интернет стал причиной их гибели, а проблема с хранилищем данных (тогда это были кассеты и их приходилось менять вручную). фейсбук бы точно взлетел, но, скорее всего, лег бы в скором времени %)
упс, пропустил его аргумент «мне лень писать тесты для всего» %)
Такой подход не есть хорошо по трем простым причинам:
1) «Писать код, как будто вы его тестируете» это как вообще? Думать про моки, кейсы и ассерты? Но ведь TDD не заставляет писать код правильно. Оно лишь дает обратную связь, по которой можно сделать вывод о принятом архитектурным решении. Нет тестов — нет обратной свяи — говнокод.
2) Не покрывая бОльшую часть кода тестами, изменять (в том числе рефакторить) код будет невозможно. После одного изменения, которое что-то поломает, тесты скажут всё ок, грин бар, потому, что автор посчитал излишними для тестирования эту часть кода. (это самое ужасное, когда тесты лгут что все нормально, а через некоторое время выясняется, что что-то работает совсем не так, как ожидается)
3) Унит-тесты не только проверка на то, что ничего не ломается, это еще и отличная документация как пользоваться этим кодом.
Поэтому резюме должно быть:
Читать про TDD и четко следовать его принципам.
ps: о 2-ом пункте писали уже, но для полноты пусть будет еще раз.
Ничего и не намешал %) Я не знал про разделение тестов на «Scenario» и «Specification», но в контексте Behat и вообще как BDD выглядит сейчас, можно говорить что это «Scenario Tests»
BDD — это эволюция TDD
BDD — это больше эволюция процесса разработки ПО, а не TDD (замену test на should я бы назвал рекомендацией, а не эволюцией).
Вообще я отвечал куда делся TDD, и последний комментарий — «BDD — это практика, объединяющая в себе TDD, DDD и Acceptance TDP» — в закладки.
Забыл отметить. В BDD есть интересная особенность. Тесты начинаются не с префикса 'test' (как в PHPUnit и других фреймворках), а начинаются с (или содержат) ensureThat (убедиться что) и should (должно). Это практику хорошо использовать для написания хороших unit тестов тоже, т.е. вместо:
public function testTotalFee{/*php*/}
будет
/* @test */
public function totalFeeShouldIncludeOurFeeAndTax{/*php*/}
Это не смена. Хотя и BDD выросло из TDD, TDD никто не отменял и не заменял.
BDD относится к Acceptance Tests, т.е. грубо говоря вы пишите пользовательские сценарии на обычном английском (можно и на русском) языке, given/when/then и автоматическая среда тестирования проверяет что результат соответствует then. Такие вот тесты интерфейса. Классы, объекты и тому подобная функциональная часть никуда не делась, поэтому Unit тесты по-прежнему надо писать с помощью TDD.
Как примерно процесс выглядит хорошо написано тут.
PS: Не знаю почему такой шум вокруг BDD, наверно, кушать хочется всем, а про TDD слушать уже надоело %)
Начни в свое время рубисты переходит на более интересные языки
(оффтоп, по-моему, кроме python и не было ничего в то время)
В том то и дело, что PHP не относился к более интересным язык и вообще интересным. На руби остались, да, написали рельсы.
Про треды был просто пример темпа развития PHP (в нем нет даже намеков на
это как в руби).
Если язык не так важен, то почему ни у кого нет желания переходить с других языков писать тот самый качественный код на PHP? потому, что он, как язык, ничем не примечателен и допустил слишком много legacy-программистов и legacy-кода.
Проблема в языках тоже. ЯП должен поощрять и подталкивать к написанию хорошего кода.
Вообще, на тему «можно написать и использовать». А что было придумано в PHP за все его время существования? Ничего. Все (абсолютно все?) идеи копируются из других языков. Мы только в 2010 увидим «правильные» веб фреймворки, ORM, BDD-фреймворки. Возможно, потому, что это стало возможно только с появлением PHP 5. Сейчас многие языки разиваются в сторону распараллеливания и тредов. Можно ли это в пхп написать и использовать? Нет, никто не будет писать. Неизвестно даже будет ли UTF-8 и PHP 5.6 вообще…
Ну а Behat клевый.
вариант с айпи не очень удобен, это значит что с работы, из дома и/или просто кафе пользоваться такой системой нельзя. Большая часть пользователей будет просто отключать ее от незнания или таких неудобств. я такой фичи даже в интернет банковских системах не вижу сейчас
похитить их все еще возможно да, но такое решение дает два преимущества (из статьи оригинала выделю их):
1. Атакующий получит доступ только на некоторое время
2. Жертва узнает об этом
Если не использовать series, то у похитителя будет свой remember me токен, который он может использовать когда угодно и жертва даже не будет
подозревать об этом.
По-моему не хватает в статье нормального введения. Потому что щас в качестве введения «разницу между TDD и BDD», а какая может быть разница если одно лежит в основе другого?
Изучив историю появления BDD, можно сделать следующие выводы:
1. Многие разработчики не знали как и не умели писать хорошие тесты используя TDD
2. Придумывают заменить слово test на should / ensure that, называют это BDD
3. BDD можно использовать с любым unit test framework-ом
4. Идея развивается, придумываются спецификации, ориентированость на user cases, а не на техническую сторону
5. Появляются BDD framework-и, которые больше подходят для написания функциональных тестов.
5. TDD не исчез и его нужно применять (стараясь использовать стиль BDD)
6. BDD — acceptance tests
Мне тоже интересно найти ответ на вопрос почему BDD может быть заменой TDD.
Вся идея BDD это использовать слова вроде should и ensure. Всё. В чем эволюция?
Почему нужно было создавать столько новых BDD фреймворков, а не оформить BDD в некоторый набор рекомендаций по написанию TDD и использовать существующие фреймворки?
И по-моему, пример №3 лучше чем пример с BDD %)
Такой подход не есть хорошо по трем простым причинам:
1) «Писать код, как будто вы его тестируете» это как вообще? Думать про моки, кейсы и ассерты? Но ведь TDD не заставляет писать код правильно. Оно лишь дает обратную связь, по которой можно сделать вывод о принятом архитектурным решении. Нет тестов — нет обратной свяи — говнокод.
2) Не покрывая бОльшую часть кода тестами, изменять (в том числе рефакторить) код будет невозможно. После одного изменения, которое что-то поломает, тесты скажут всё ок, грин бар, потому, что автор посчитал излишними для тестирования эту часть кода. (это самое ужасное, когда тесты лгут что все нормально, а через некоторое время выясняется, что что-то работает совсем не так, как ожидается)
3) Унит-тесты не только проверка на то, что ничего не ломается, это еще и отличная документация как пользоваться этим кодом.
Поэтому резюме должно быть:
Читать про TDD и четко следовать его принципам.
ps: о 2-ом пункте писали уже, но для полноты пусть будет еще раз.
Странное резюме. Если вы знаете TDD (об этом ссылка в топике), то зачем писать «как будто», когда можно писать сначала тесты, потом код?
BDD — это больше эволюция процесса разработки ПО, а не TDD (замену test на should я бы назвал рекомендацией, а не эволюцией).
Вообще я отвечал куда делся TDD, и последний комментарий — «BDD — это практика, объединяющая в себе TDD, DDD и Acceptance TDP» — в закладки.
будет
BDD относится к Acceptance Tests, т.е. грубо говоря вы пишите пользовательские сценарии на обычном английском (можно и на русском) языке, given/when/then и автоматическая среда тестирования проверяет что результат соответствует then. Такие вот тесты интерфейса. Классы, объекты и тому подобная функциональная часть никуда не делась, поэтому Unit тесты по-прежнему надо писать с помощью TDD.
Как примерно процесс выглядит хорошо написано тут.
PS: Не знаю почему такой шум вокруг BDD, наверно, кушать хочется всем, а про TDD слушать уже надоело %)
(оффтоп, по-моему, кроме python и не было ничего в то время)
В том то и дело, что PHP не относился к более интересным язык и вообще интересным. На руби остались, да, написали рельсы.
Про треды был просто пример темпа развития PHP (в нем нет даже намеков на
это как в руби).
Если язык не так важен, то почему ни у кого нет желания переходить с других языков писать тот самый качественный код на PHP? потому, что он, как язык, ничем не примечателен и допустил слишком много legacy-программистов и legacy-кода.
За Behat спасибо.
Вообще, на тему «можно написать и использовать». А что было придумано в PHP за все его время существования? Ничего. Все (абсолютно все?) идеи копируются из других языков. Мы только в 2010 увидим «правильные» веб фреймворки, ORM, BDD-фреймворки. Возможно, потому, что это стало возможно только с появлением PHP 5. Сейчас многие языки разиваются в сторону распараллеливания и тредов. Можно ли это в пхп написать и использовать? Нет, никто не будет писать. Неизвестно даже будет ли UTF-8 и PHP 5.6 вообще…
Ну а Behat клевый.
1. Атакующий получит доступ только на некоторое время
2. Жертва узнает об этом
Если не использовать series, то у похитителя будет свой remember me токен, который он может использовать когда угодно и жертва даже не будет
подозревать об этом.
Изучив историю появления BDD, можно сделать следующие выводы:
1. Многие разработчики не знали как и не умели писать хорошие тесты используя TDD
2. Придумывают заменить слово test на should / ensure that, называют это BDD
3. BDD можно использовать с любым unit test framework-ом
4. Идея развивается, придумываются спецификации, ориентированость на user cases, а не на техническую сторону
5. Появляются BDD framework-и, которые больше подходят для написания функциональных тестов.
5. TDD не исчез и его нужно применять (стараясь использовать стиль BDD)
6. BDD — acceptance tests
Так?
Вся идея BDD это использовать слова вроде should и ensure. Всё. В чем эволюция?
Почему нужно было создавать столько новых BDD фреймворков, а не оформить BDD в некоторый набор рекомендаций по написанию TDD и использовать существующие фреймворки?
И по-моему, пример №3 лучше чем пример с BDD %)