[истории успеха] Разработка через тестирование

Т.е. ты даже детской ошибки в регеспе не видишь

это называется за деревьями леса не видишь, что, впрочем, характерно для профанов

И да, не ленись сразу писать нормальные тесты — потом все-равно придется)

> не нужен вопрос, мне с тобой и так всё понятно, проблема в другом - ты порешь чушь и путаешься даже в 1-м определении, но делаешь это столь самозабвенно, что кто-то может может на твои рассуждения повестись, это было бы не очень хорошо

Бида-бида! От пользователей лора скрывают правду!!11


Специально для тебя, мой милый, я разжую, что такое рефакторинг на примере и заодно покажу, почему он не живет вместе с тестами.

Есть код с функцией f(a,b). К нему есть пачка тестов на инварианты. В какой-то момент эта функция перестаёт нас устраивать, её надо заменить на f(a,c) и f(b,c). Старые инварианты касательно a и b остаются в силе, добавляются новые относительно c. Поскольку у нас поменялся контракт функций (поясняю для не свинов - их апи), старая пачка тестов _вся целиком_ летит в помойку, а на их место выходит новая пачка, которая на две трети повторяет старую. Итого - очень много дурной работы на ровном месте.

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

Специально для тебя, мой милый

shty@shty-H55M-S2:~$ uname -a
Linux shty-H55M-S2 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

fail

> смотри

только ты там опять ничего не увидишь, ибо свин от программирования

Для не свина ты удивительно не сообразителен. Я не просил привести пример тестового фреймворка. Их я в состоянии нагуглить сам (как бы тебе не хотелось верить в обратное). Я просил привести пример, когда синхронные с кодом _тесты_ (а не фреймворки) давали заметный выигрыш для тестируемого кода.

> это называется за деревьями леса не видишь

Я всегда так буду отмазываться, когда мне надо будет сделать вид, что мой пример не облажался, когда я пространно и туманно рассуждаю о высоких материях. «Я вся в кино, я вся в искусстве».©

> shty@shty-H55M-S2:~$ uname -a

Linux shty-H55M-S2 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

fail

Лоробот, с никнеймом shty, выпал в корку? Ну вот, а говорили «TDD, TDD»...

Есть код с функцией f(a,b)

на примере какого языка происходит рассмотрение, Python?

Есть код с функцией f(a,b). К нему есть пачка тестов на инварианты.

не очень понятно что Вы называете «пачкой тестов на инварианты»

В какой-то момент эта функция перестаёт нас устраивать, её надо заменить на f(a,c) и f(b,c). Старые инварианты касательно a и b остаются в силе, добавляются новые относительно c.

ошибка проектирования, в явном виде, если такое регулярно происходит - надо либо менять архитектора, либо подход к проектированию

Поскольку у нас поменялся контракт функций (поясняю для не свинов - их апи), старая пачка тестов _вся целиком_ летит в помойку, а на их место выходит новая пачка, которая на две трети повторяет старую.

1. я с Вас фигею, слушая Вас, можно подумать, что при таком раскладе не придётся переписывать код во всех местах, где он используется и заново проверять всё, запуская ручками
2. если у Вас постоянно вызывается одна и та же функция на разных данных - это, как правило, автоматизируется с помощью вспомогательных конструкций, и, следовательно, меняется сравнительно легко

Итого - очень много дурной работы на ровном месте.

но виновен не жираф (с)

а виновен тот, кто практику частого изменения API привносит в процесс разработки

Я не просил привести пример тестового фреймворка. Их я в состоянии нагуглить сам (как бы тебе не хотелось верить в обратное).

ты такой талантливый свинопрограммер, как ты не смог разобраться в том что тебе было приведено?

это тебе не пример тестового фреймворка, это набор тестов, закрывающий определённый функционал этого фреймворка, и его написали в google и в google же широко используют

так что можешь сливать дальше, и кричать, что ненужно, квалифицированные разработчики знают как работать эффективно, и какие инструменты для этого подходят хорошо

Я просил привести пример, когда синхронные с кодом _тесты_ (а не фреймворки) давали заметный выигрыш для тестируемого кода.

там это есть, но чтобы это увидеть надо иметь мозг

> shty@shty-H55M-S2:~$ uname -a

Linux shty-H55M-S2 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

fail

Лоробот, с никнеймом shty, выпал в корку? Ну вот, а говорили «TDD, TDD»...

1. это не корка, понимаю, для тебя это сложно, так что просто поверь
2. это пруф что у меня не MacOS, так что нет совершенно никакого резона тебе называть меня «милым»

> на примере какого языка происходит рассмотрение, Python?

Какая разница? Пусть будет С для простоты.

не очень понятно что Вы называете «пачкой тестов на инварианты»

К сто пятидесятому посту, выясняется, что ты не понимал половины речи собесдника - ни рефакторинг, ни инварианты. Очень мило.

ошибка проектирования, в явном виде, если такое регулярно происходит - надо либо менять архитектора, либо подход к проектированию

А! Ты из волшебного мира, где протип каждой функции нарисован «архитектром» в умл? Ну, тогда понятно. Вопросов больше не имею.

1. я с Вас фигею, слушая Вас, можно подумать, что при таком раскладе не придётся переписывать код во всех местах, где он используется и заново проверять всё, запуская ручками

Конечно придётся и (о, ужас!!1) даже тесткейсы на новом билде придётся прогнать в полном объёме. Жестокая реальность, которую тупая и унылыя копипаста кода тестов нисколько не скрашивает.

виновен тот, кто практику частого изменения API привносит в процесс разработки

Это «stable api is nonsense» и называется рефакторинг - краеугольный камень столь любимого тобою agile.

> это тебе не пример тестового фреймворка, это набор тестов, закрывающий определённый функционал этого фреймворка

И не является частью этого фреймворка? ;)

квалифицированные разработчики знают как работать эффективно, и какие инструменты для этого подходят хорошо

Ты забыл ™ после «квалифицированные разработчики»

там это есть, но чтобы это увидеть надо иметь мозг

Что «это»? Ты должно быть, кое чего не догоняешь, хоть и весь из себя несвинопрограммер. Речь идёт о профите синхоронной поддержке актуальных тестов. Увидеть этот профит можно только на изменениях кода во времени. Этого нельзя увидеть на единовременном срезе кода _в принципе_. Дошло или нет?

> это пруф что у меня не MacOS, так что нет совершенно никакого резона тебе называть меня «милым»

Ах, прости, дорогуша! Я понимаю, что «свин», «туп» и так далее гораздо милее твоему сердцу, лапочка. :3

Есть код с функцией f(a,b).

Старые инварианты касательно a и b остаются в силе, добавляются новые относительно c

А ты точно понимаешь что такое инвариант? Инвариант - это утверждение, которое остается истинным во время выполнения какого-то алгоритма. Как ты собрался тестировать инвариант на локальных переменных функции?

Если есть функция f(a, b), то тесты будут на все краевые случаи зависимости значения функции от аргументов. Вообще когда идет речь об тестировании инвариантов я подразумевают тестирование состояния некоторого объекта, как-то так:

test_smth() {
  obj = new ...
  check_valid(obj)
  obj.call...
  check_valid(obj)
}

Речь идёт о профите синхоронной поддержке актуальных тестов.

Настолько сильно перелопачивать код, что все тесты летят на помойку как ни крути вредно. Что нам тесты придется переписывать, что тебе в ручную весь код перетестировать. Проект должен развивать эволюционно, а не революцонно.

То есть ты пытаешься доказать проблему подхода на вообще фатальном случае. Это все равно что доказывать неэффективность бронежилета на примере взрыва атомной бомбы.

> на примере какого языка происходит рассмотрение, Python?

Какая разница? Пусть будет С для простоты.

в таком случае Ваше api не валидно с точки зрения синтаксиса

какая разница? хочу попробовать понять причины косяков с постоянно изменяющимися api

> не очень понятно что Вы называете «пачкой тестов на инварианты»

К сто пятидесятому посту, выясняется, что ты не понимал половины речи собесдника - ни рефакторинг, ни инварианты. Очень мило.

уважаемый, Вы столь часто подменяете понятия, что я уж лучше лишний раз переспрошу, нежели буду спорить с Вами ни о чём

итак, готовы ответить?

> ошибка проектирования, в явном виде, если такое регулярно происходит - надо либо менять архитектора, либо подход к проектированию

А! Ты из волшебного мира, где протип каждой функции нарисован «архитектром» в умл?

нет, я из другого мира, правда это к делу не относится

я правильно понял что у Вас api каждый проектирует как у него левая пятка зачешется?

> 1. я с Вас фигею, слушая Вас, можно подумать, что при таком раскладе не придётся переписывать код во всех местах, где он используется и заново проверять всё, запуская ручками

Конечно придётся и (о, ужас!!1) даже тесткейсы на новом билде придётся прогнать в полном объёме.

про какие тесткейсы Вы сейчас говорите?

Жестокая реальность, которую тупая и унылыя копипаста кода тестов нисколько не скрашивает.

тупая и унылая копипаста может, в принципе, что-то скрашивать? тяжко у Вас там

> виновен тот, кто практику частого изменения API привносит в процесс разработки

Это «stable api is nonsense» и называется рефакторинг - краеугольный камень столь любимого тобою agile.

ты не понимаешь о чём говоришь, стягиваешь всё в кучу

начёнм с того, что столь нежно цитируемый тобой agile, это вообще просто рекомендации, и там нигде не сказано про нестабильность api

теперь двигаемся дальше

я Вам в который раз приводу весьма и весьма невусмысленное определение рефакторинга:

Рефакторинг (англ. refactoring) — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы.

и этого определения явно следует, что рефакторинг не предполагает изменения api

и рефакторинг функции или класса под тестами не предполагает изменение их интерфейса

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

> это тебе не пример тестового фреймворка, это набор тестов, закрывающий определённый функционал этого фреймворка

И не является частью этого фреймворка? ;)

нет, а должны?

Речь идёт о профите синхоронной поддержке актуальных тестов.

вот которую страницу ты не поймёшь простой вещи, не «поддержка актуальных тестов» имеет место быть, а управляемое тестами написание кода

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

Увидеть этот профит можно только на изменениях кода во времени. Этого нельзя увидеть на единовременном срезе кода _в принципе_. Дошло или нет?

я тебе привёл ссылку не на один файл, а на репозитарий - смотри, кто тебе мешает? :)

а согласно TDD ты его сохраняешь, и всё, больше никакой разницы

Ну и инвестируешь еще в архитектуру, что бы она хорошо тестами покрывалась.

>а согласно TDD ты его сохраняешь, и всё, больше никакой разницы

Ну и инвестируешь еще в архитектуру, что бы она хорошо тестами покрывалась.

да там куча профитов есть, но пусть он хотя бы базовый принцип поймёт