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

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

А практик скажет збс код?

А практик скажет збс код?

Во видишь я почти угадал ответ Андрия:)

Мне с таким кодом работать удобно.

737 MAX это не проблема софта. Программистам выдали ТЗ, они его реализовали. А проблема кривого ТЗ другого плана. Опять же, есть верификация, это твои 100%. По сути мы можем математически доказать, что некоторый код работает. Но это дорого. Но в целом вопрос целесообразности упирается в цифры. Если у нас большинство вознкающих багов никак не ловят Unit-тесты, то зачем они нужны? Опять же, конкректный пример: https://github.com/warmcat/libwebsockets/blob/39f0c3c6a08165433fe4851777d95dbb6f017791/lib/core-net/close.c#L346 словами опиши, как бы ты написал для этой функции Unit тест

А тем, кто это будет делать после тебя, будет удобно?

А тем, кто это будет делать после тебя, будет удобно?

Мне с таким кодом работать удобно.

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

А я и не спорю

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

Я о том, что декомпозировать надо в процессе разработки, и тесты здесь ни при чем

Большинство - не значит все. Потому и существуют разные виды тестов. В приведённом коде надо еще поковырятся, я на сях уже лет 15 ничего не писал. Но на первый взгляд, будет (не) много гемора с проверкой закрытия соединения. На джаве я это смогу сделать, на сях надо разбираться

Короче, опять начнётся вилами по воде

так сложилось :) обычно такой будет ответ

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

Короче, опять начнётся вилами по воде

Мы говорим конкректно про Unit тесты. В общем моё видение, что они используются не очень часто и малополезны. Возможно, есть ситуации, когда это работает, но за 20 лет на практике я с ними особо не встречался. А функциональные тесты очень даже хорошо себя показывают и используются

Ну так в трекер же записать что-то нужно. "Проводил анализ оптимизации тестирования"

Большинство - не значит все. Потому и существуют разные виды тестов. В приведённом коде надо еще поковырятся, я на сях уже лет 15 ничего не писал. Но на первый взгляд, будет (не) много гемора с проверкой закрытия соединения. На джаве я это смогу сделать, на сях надо разбираться

Мы говорим конкректно про Unit тесты. В общем моё видение, что они используются не очень часто и малополезны. Возможно, есть ситуации, когда это работает, но за 20 лет на практике я с ними особо не встречался. А функциональные тесты очень даже хорошо себя показывают и используются

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

Моя практика больше в том, что Unit тесты это религия.

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

ну.. религия или нет, но, в рамках написания либы те де юнит-тесты работают как неплохая документация, но тут уже вопрос не об жтом, конечно же

Моя практика больше в том, что Unit тесты это религия.

Дык зачисление денег на карточку это функциональный тест. А Unit тест это тесты на каждый из 1000 методов, которые будут вызваны в результате этого кейза.

Сколько я не юзал либ, юнит-тесты скорее редкость :)

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

Посмотри у них демозанятия, дни открытых дверей, если будешь понимать, о чем речь - иди

Есть вакансии, где в обязанностях инженера это входит

Согласен, если это доходит до абсурда, как в книге Бэка, то да

В книге Бэка много всего, и он много раз подчёркивает, что всё работает вместе, а не по отдельности. Так что юзай парное программирование, TDD, общее владение кодом, ... Не говоря о том, что это относится к одной отрасли

Ок, спасибо, а по качеству подачи материала и по обучающему процессу к них нормик?

Только сколько их на самом деле делают. На моей практике редко кто больше 20% кода юнитами покрывает. Иной раз бывало, что вообще никт не пишет, пока манагер люлей не даст, у него же показатели)))

От препода зависит. Они чуваки грамотные, но вот подавать материал не все могут нормально. Например, Лапин и Петрелевич еще норм, а есть те, у которых реально засыпаешь)))

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

Ок, спасибо за инфу) а ты учился у них?)

Тесты для слабых)

Прям хочу увидеть как вы транзакцию протестируете :) не замокав весь внешний код ) по факту оставив от него пшик

О дааааа)) обожал таких разрабов!) особенно на одном проекте, где за баги давали бонусы, а у разрабов могли резануть премию)

Ок, спасибо за инфу) а ты учился у них?)

Какую ценность несут юнит тесты? Никакой? Бесконечно рефакторить?

А рефакторить уже код в целом

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

Какую ценность несут юнит тесты? Никакой? Бесконечно рефакторить?

Конечный функционал меняется?

Ну... у меня стиль написания такой, что в процессе я попробую несколько разных вариантов организации кода и выберу тот, что больше понра. А 80% кода выкинется по итогу. А если я буду писать на него вначале тесты, то...

При рефаче - нет