Программирование по принципу тесты вперёд TDD

[Степан Бабкин]

Хм. А кстати да. Интересная мысль...

На самом деле люди так и живут. Просто между решением 1 и решением 2 ждут обратной связи. Это очень дорого.

В программировании это особенно заметно. Пишется код, запускается программа, делается тест. Не работает, ок, думаем дальше. Так обычно работают хорошие программисты. Плохие на тест особо не заморачиваются.

Дима учил - не пиши код. Он не работает всё равно, потом же исправлять, это долго. Ни первый, ни второй код не работают. Думай. Делай тест. Много думай и много тестируй. Тестируй ещё. Потом пиши.

 

[Удаленный 5203]

Что-то вы мне с утра мозг взрываете. Как можно тестировать не написав код? Надо поподробнее почитать TDD, может и мы пару тестировщиков наймем

все просто. Пишете тесты - это red-green-refactor методология TDD. Прежде, чем писать код, нужно определить, что он должен и чего не должен делать. В TDD тесты не должны зависеть от конкретной реализации, иначе это будет ад в поддержке этих автотестов. Поначалу, разумеется, без имплементации, все тесты красные. По мере имплементации тесты "зеленеют" и к концу должны быть зелеными. Если меняется требование, покрытое условием, сначала переписываем тест, потом реализацию. Опять red - green. Если был сделан рефакторинг, -тесты должны оставаться зелеными.Если на изменение тестов, чтоб они не становились красными при каждом рефакторинге, тратится слишком много времени - код говно.

 

[dorotynsky]

все просто. Пишете тесты - это red-green-refactor методология TDD. Прежде, чем писать код, нужно определить, что он должен и чего не должен делать. В TDD тесты не должны зависеть от конкретной реализации, иначе это будет ад в поддержке этих автотестов. Поначалу, разумеется, без имплементации, все тесты красные. По мере имплементации тесты "зеленеют" и к концу должны быть зелеными. Если меняется требование, покрытое условием, сначала переписываем тест, потом реализацию. Опять red - green. Если был сделан рефакторинг, -тесты должны оставаться зелеными.Если на изменение тестов, чтоб они не становились красными при каждом рефакторинге, тратится слишком много времени - код говно.

Лучшее описание TDD, которое я видел!

 

[Степан Бабкин]

Лучшее описание TDD, которое я видел!

Ну, значит, 259 страниц было не зря! ?

 

[Kutlin Denis]

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

Разве на рефакторинге меняются тесты? Если конечно это не рефакторинг архитектуры модуля.

 

[dorotynsky]

Ну, значит, 259 страниц было не зря! ?

Будем переименовывать тему в "Короновирус и TDD в Германии"?

 

[dorotynsky]

Разве на рефакторинге меняются тесты? Если конечно это не рефакторинг архитектуры модуля.

В обычном случае - нет. Наоборот, в идеале, они должны без каких-либо изменений оставаться зелёными.
Другое дело, что рефакторинг рефакторингу рознь. Иногда надо 2/3 кода с нуля переписать - тогда тесты с очень немаленькой вероятностью упадут.

 

[Boris]

Нашёл алгоритм, который решает задачу? Забудь и думай дальше

вот тут я торможу.
Зачем?
Есть задача, есть ее решающий (успешно и с выполнением условий) алгоритм.
Надо браться за след. задачу, а не за след. алгоритм, иначе всю жизнь будешь решать одну задачу, нет? ?

 

[Boris]

все просто. Пишете тесты

какое счастье, что я не дожил пишу сейчас и не имею дел с нынешними "разработчиками".
Как было:
Есть задача - есть НАСТОЯЩИЕ нормальные программисты - они пишут и тестируют свое _сами_, выдают работающий код - имеем результат.
Как сейчас:
Есть задача - Пишите тесты.
Ну если это не пиз№ец, то что тогда?

А потом все удивляются, что софт весь практически глючное Г.., Машины с автопилотами сбивают людей,
и АПП про корону нихрена не работает.
Может надо "в консерватории" что-то подправить?

 

[Kutlin Denis]

Зачем - вопрос не имеющий однозначного решения. С точки зрения тактического бизнеса - все хорошо, новый алгоритм не нужен, потому что задача уже решена.
С точки зрения стратегического бизнеса - мы тратим ресурсы на прокачку персонала, чтобы в будущем быстрее решать задачи этого же уровня и быть способны решить задачи более высокого уровня.
Однако в жизни нужна гармония

 

[Kutlin Denis]

НАСТОЯЩИЕ нормальные программисты - они пишут и тестируют свое _сами_

Это широко распространенное заблуждение как раз и приводящее к приложениям работающим на отвали и валящимся на простейших ситуациях отличных от шаблонных

 

[Степан Бабкин]

Надо браться за след. задачу, а не за след. алгоритм, иначе всю жизнь будешь решать одну задачу, нет? ?

Нет, потому что это только кажется, что алгоритм правильный. Не учтена куча вводных. Тратятся лишние ресурсы. Может быть вообще это неверное решение, покрывающее только частный случай. Первое решение почти всегда неверное, если речь о разуме. Получается порождение быстрого мышления. На отвали.

Попробуй сам. Любое решение, какое угодно, например, что ответить. И последовательно запиши - ответ №1, №2, №3... и так далее. Придумай 10 ответов. Увидишь, какой будет лучше.

Мозг хитрый, он сначала пытается решить задачу, чтобы ты (да, я считаю мозг и Я - это разные сущности) просто отстал.

Может надо "в консерватории" что-то подправить?

Дык как раз потому что программисты не пишут тестов, всё и глючит ? Писать сначала тесты - это не значит кодить тесты. Это на 80% крутить задачу в голове.

 

[Kittiket]

На самом деле люди так и живут. Просто между решением 1 и решением 2 ждут обратной связи. Это очень дорого.

В программировании это особенно заметно. Пишется код, запускается программа, делается тест. Не работает, ок, думаем дальше. Так обычно работают хорошие программисты. Плохие на тест особо не заморачиваются.

Дима учил - не пиши код. Он не работает всё равно, потом же исправлять, это долго. Ни первый, ни второй код не работают. Думай. Делай тест. Много думай и много тестируй. Тестируй ещё. Потом пиши.

Мне кажется это немного устарело даже без ТДД которым я так и не проперлась. Тесты сейчас пишутся на все можно и нельзя, без них никто код не примет, у нас тут угарают по хардкору и тестируют даже геттеры с сеттерами, раздражает ппц.
И вообще, обычно нет какой-то прям хардкорной алгоритмики, по крайней мере не в том с чем я работаю последние годы. Это скорее как встроить новую функцию в это старое прогнившее дерьмо чтобы оно не развалилось. А не как отсортировать поэффективнее или перевернуть список или еще что-нить такое.

 

[Степан Бабкин]

Мне кажется это немного устарело

Да, мне 40 лет. Спасибо, что напомнили.

 

[Kittiket]

Что-то вы мне с утра мозг взрываете. Как можно тестировать не написав код? Надо поподробнее почитать TDD, может и мы пару тестировщиков наймем

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

 

[Kutlin Denis]

Группировать тесты по тематике и задачам уже не модно?

Ну так себе вышло

Видимо как изначально задание всем подготовлено, так и вышло...

 

[Kittiket]

Да, мне 40 лет. Спасибо, что напомнили.

Ну мне 35, не сильно большая разница так-то, это если про возраст.

 

[Степан Бабкин]

Да. Самое тупое что можно сделать с TDD - это написать тестов на функциональность типа геттеров и радоваться. В геттерах не должно быть никакой логики, а кто так делает - тот должен сам себе сделать сеппуку.

TDD - это скорее про Integration tests, если уж на то пошло. По крайней мере, начинать надо с них. И конечно не надо фигачить в отрыве от производства.

Есть task, вот на неё и пиши сначала integration test - на всю таск во всём многообразии, да. Как раз хорошо проверяется, кто здесь PO, а кто погулять вышел...

 

[Степан Бабкин]

Ну мне 35, не сильно большая разница так-то, это если про возраст.

Видите ли, когда я учился, мне было 18. И даже ООП ещё в новинку был.

 

[Kittiket]

Видите ли, когда я учился, мне было 18. И даже ООП ещё в новинку был.

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