powered by simpleCommunicator - 2.0.50     © 2025 Programmizd 02
Форумы / Java [игнор отключен] [закрыт для гостей] / Тестирование. Что именно тестировать? Как определить середину?
25 сообщений из 361, страница 11 из 15
Тестирование. Что именно тестировать? Как определить середину?
    #39801969
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ОзверинАндрей Панфилов, я пишу о том, что не бывает проектов(а если они и есть, я ни разу их не видел), где не было б технического долга вовсе. А раз таких проектов нет, то ценность совета: просто все сделайте правильно и рефакторинг не нужен будет - падает на порядок ниже советов вроде: как писать код, чтобы его потом можно было б отрефакторить в сжатые сроки.Мы говорим о разных вещах, я изначально спрашивал: как определить когда нужно проводить рефакторинг, единственный ответ, который я получил звучал так: ну вот у нас тут члены команды на сходке предлагают что-то отрефакторить, а мы потом думаем нужно это или нет - для меня это звучит несколько дико, по следующими причинам:
- складывается впечатление что у продукта нет владельца, потому что предложения о переделке исходит от кого-то "со стороны"
- точно также складывается впечатление, что члены команды вместо того чтобы закрывать текущие CR только и занимаются тем, что выискивают чтобы такого отрефакторить
по моему мнению:
- рефакторинг может потребоваться в случаях:
-- мы закрываем баги производительности или внедряем фичу, которую до этого вообще никак не предвидели
-- нужно сделать срочно-пресрочно: сразу на ревью заводим задачу на рефакторинг
- в остальных случаях, когда мы рефакторим код, который был закоммичен совсем недавно - это дикость
...
Рейтинг: 0 / 0
Тестирование. Что именно тестировать? Как определить середину?
    #39801978
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonАндрей ПанфиловЕдем дальше, вот мое видение на то, как тот же тест должен выглядеть:

Код: java
1.
2.
	assertThat(countryList, hasSize(expectedNames.size()));
	assertThat(countryList, contains(HamcrestDemo::aCountryNamed, expectedNames));



Функциональный стиль который вы предлагаете не имеет никакого значения. Он не добавляет
и не уменшает понимания к коду теста. Хотя за использования Хамкрест я делаю плюсик.

Я-бы оставил тест как есть в первом варианте. При прочих равных условиях если стоит
вопрос менять или не менять тест я выбираю - не менять. Тест - это закон. Закон по которому
должен работать код. И надо иметь очень много оснований чтоб менять сам тест.Есть большая разница в поведении теста: в одном случае он просто пишет "ничего не работает", а потом вы идете и начинаете при помощи отладчика выяснять что же на самом деле ему не понравилось, во втором случае он пишет что именно пошло не так - т.е. какие данные ожидались и какие пришли (у нас например тесты на селениуме идут 3 часа, там и видосики записываются, и сетевой трафик, и скриншоты делаются - исправления можно сделать особо не вникая в код). В целом же я с вами согласен в том плане, что переписывать такие тесты - дурная затея, их проще в таком виде не пропускать вообще - опять же, тесты должны писать профессионалы.
...
Рейтинг: 0 / 0
Тестирование. Что именно тестировать? Как определить середину?
    #39801988
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Панфилов, я понимаю, о чем вы говорили изначально, но я отвечал именно на то, что выделил в отдельную вашу цитату. В остальном, да, надо нанимать грамотных специалистов, поднимать культуру кодирования, проводить код ревью, учить людей палкой писать понятные именования переменных и все такое. Но в итоге все проекты приходят все равно к тому, что рефакторить надо.
...
Рейтинг: 0 / 0
Тестирование. Что именно тестировать? Как определить середину?
    #39801998
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Лет 5 назад один архитектор предложил мне подход к разработке.

Вы берете текст user story. И копи-пастите его в код. Исходник у вас - окрашивается
в красный цвет. Но не беда. Вы хладнокровно. Потихоньку выделяете в нем verbs,
делаете методы. Делаете основное ветвление (99% юзер стори базируется на веточках
или кейсах типа если пришел платеж такой-то то делаем тото и т.д). Далее вы рефакторите
его по правилам Java, сохраняя максимально семантику английского текста.
Здесь в помошь будет шаблон Builder. И далее в какой-то момент - вуаля.
У вас - работающий код который имеет очень точное отображение на бизнес-стори.
Реально. Здесь - главное не скатиться в технократию и не делать в if (...) цепочку предикатов.
Надо сохранить английский текст.

В этом есть принципиальная разница например в сравнении с С++ разработкой
где принято сокращать переменные до безсмыслиц со знаком подчеркивания или
не дай бох венгерских нотаций.

Я попробовал эту методику и предлагаю вам всем. Попробуйте когда зайдет новая
user story, воплотить этот подход.
...
Рейтинг: 0 / 0
Тестирование. Что именно тестировать? Как определить середину?
    #39802022
alex55555
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Панфиловрекомендую вам купить любую такую книжку, потом сжечь, обоссать и выкинуть.
Всё же не стоит так категорично подходить к объективным свойствам мироздания.

Люди неидеальны. Это факт. Отсюда много следствий.

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

В целом надо искать какой-то компромисс между "как надо" и "что реально есть". Хотя я поддерживаю идею бить по рукам на форумах за неумелые предложения, но, например, так же бить по рукам в коллективе разработчиков - ведёт к текучке кадров и застою оставшихся в привычных для них нишах. И это, естественно, дополняется застоем сверху. Ведь почему надо освоить бюджет инвестора? Да потому, что инвестор верит, что его деньги здесь будут расти. Не кто-то его заставляет всё отдать, а он сам, по глупости или в надежде на чудо или ещё как-то необоснованно, всё отдаёт. И когда вот так отдают, ну как могут с такой неэффективностью сочетаться реально эффективно организующие процесс разработчики? Любой сопляк заявит перед инвестором "да можно в 100 раз круче сделать!!!" и инвестор поверит, потому что хочет верить. А опытные приведут лишь технические аргументы против, чего инвестор понимать не обучен.
...
Рейтинг: 0 / 0
Тестирование. Что именно тестировать? Как определить середину?
    #39802025
alex55555
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonФункциональный стиль который вы предлагаете не имеет никакого значения. Он не добавляет и не уменшает понимания к коду теста.
Он сокращает код до двух строчек, что улучшает читаемость, а значит и понимание кода.

Хотя можно и без функционального стиля в две строчки уложить. Но вероятно, что строчки будут длиннее. А вообще однозначно лучше напрячь разработчиков на хотя бы понимание функционального стиля, что бы прочитать чужое могли, ну и может иногда своё сократить.
...
Рейтинг: 0 / 0
Тестирование. Что именно тестировать? Как определить середину?
    #39802030
alex55555
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonЛет 5 назад один архитектор предложил мне подход к разработке.
Там, где простым является текстовое описание, столь же простой является и программная реализация. Но если за некоторым словом "сделать" скрываются бездны смыслов, то такое описание нельзя назвать простым, оно просто неполное, и тогда никакая программная реализация "в буквальном смысле" не поможет.
...
Рейтинг: 0 / 0
Тестирование. Что именно тестировать? Как определить середину?
    #39802040
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonВы берете текст user story. И копи-пастите его в код. Исходник у вас - окрашивается
в красный цвет. Но не беда. Вы хладнокровно. Потихоньку выделяете в нем verbs,
делаете методы. Делаете основное ветвление (99% юзер стори базируется на веточках
или кейсах типа если пришел платеж такой-то то делаем тото и т.д). Далее вы рефакторите
его по правилам Java, сохраняя максимально семантику английского текста.
Здесь в помошь будет шаблон Builder. И далее в какой-то момент - вуаля.
У вас - работающий код который имеет очень точное отображение на бизнес-стори.
Реально. Здесь - главное не скатиться в технократию и не делать в if (...) цепочку предикатов.
Надо сохранить английский текст.Теперь давайте спустимся с небес на землю...
вот то что пишут адепты TDD:
Three Laws of TDD1. You must write a failing test before you write any production code.
2. You must not write more of a test than is sufficient to fail, or fail to compile.
3. You must not write more production code than is sufficient to make the currently failing test pass.
внимание вопрос: я думаю ни у кого нет сомнений, что тест должен тестировать работу некого API, соответственно без существования предмета тестирования, т.е. API, тест будет не то что падать, он даже компилироваться не будет, как разрешить ситуацию в этом случае? получается что API-таки нужно сделать раньше теста, но как же тогда быть с "You must write a failing test before you write any production code"? или нужно положить болт на все удобства и гонять тесты через рефлексию?
...
Рейтинг: 0 / 0
Тестирование. Что именно тестировать? Как определить середину?
    #39802053
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Панфиловвнимание вопрос: я думаю ни у кого нет сомнений, что тест должен тестировать работу некого API, соответственно без существования предмета тестирования, т.е. API, тест будет не то что падать, он даже компилироваться не будет, как разрешить ситуацию в этом случае? получается что API-таки нужно сделать раньше теста, но как же тогда быть с "You must write a failing test before you write any production code"? или нужно положить болт на все удобства и гонять тесты через рефлексию?

есть третий, промежуточный или вариация на тему.
Одна вариация: пишется тест и он не компилируется. Потом добавляется интерфейс и методы(которые не компилируются), а потом все это обрастает логикой(имплементацией).

Другая вариация: есть некое ядро разрабов-архитекторов, которые создают "скелет" приложения исключительно из интерфейсов, а имплементацию уже спускают на tdd отдел.
...
Рейтинг: 0 / 0
Тестирование. Что именно тестировать? Как определить середину?
    #39802056
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alex55555maytonФункциональный стиль который вы предлагаете не имеет никакого значения. Он не добавляет и не уменшает понимания к коду теста.
Он сокращает код до двух строчек, что улучшает читаемость, а значит и понимание кода.

Хотя можно и без функционального стиля в две строчки уложить. Но вероятно, что строчки будут длиннее. А вообще однозначно лучше напрячь разработчиков на хотя бы понимание функционального стиля, что бы прочитать чужое могли, ну и может иногда своё сократить.
Здесь - самый лучший кейс - голосование внутри команды. Если команда решит что ФП стиль в данном случае
лучше то я не буду спорить.

Моё мнение. Хороший тест - неизменяемый тест.
...
Рейтинг: 0 / 0
Тестирование. Что именно тестировать? Как определить середину?
    #39802057
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alex55555maytonЛет 5 назад один архитектор предложил мне подход к разработке.
Там, где простым является текстовое описание, столь же простой является и программная реализация. Но если за некоторым словом "сделать" скрываются бездны смыслов, то такое описание нельзя назвать простым, оно просто неполное, и тогда никакая программная реализация "в буквальном смысле" не поможет.
Приведите пример.
...
Рейтинг: 0 / 0
Тестирование. Что именно тестировать? Как определить середину?
    #39802060
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей ПанфиловmaytonВы берете текст user story. И копи-пастите его в код. Исходник у вас - окрашивается
в красный цвет. Но не беда. Вы хладнокровно. Потихоньку выделяете в нем verbs,
делаете методы. Делаете основное ветвление (99% юзер стори базируется на веточках
или кейсах типа если пришел платеж такой-то то делаем тото и т.д). Далее вы рефакторите
его по правилам Java, сохраняя максимально семантику английского текста.
Здесь в помошь будет шаблон Builder. И далее в какой-то момент - вуаля.
У вас - работающий код который имеет очень точное отображение на бизнес-стори.
Реально. Здесь - главное не скатиться в технократию и не делать в if (...) цепочку предикатов.
Надо сохранить английский текст.Теперь давайте спустимся с небес на землю...
вот то что пишут адепты TDD:
Three Laws of TDD1. You must write a failing test before you write any production code.
2. You must not write more of a test than is sufficient to fail, or fail to compile.
3. You must not write more production code than is sufficient to make the currently failing test pass.
внимание вопрос: я думаю ни у кого нет сомнений, что тест должен тестировать работу некого API, соответственно без существования предмета тестирования, т.е. API, тест будет не то что падать, он даже компилироваться не будет, как разрешить ситуацию в этом случае? получается что API-таки нужно сделать раньше теста, но как же тогда быть с "You must write a failing test before you write any production code"? или нужно положить болт на все удобства и гонять тесты через рефлексию?
Я прошу прощения. Я описывал методику не для написания тестов. А для написания
основной бизнес-логики.
...
Рейтинг: 0 / 0
Тестирование. Что именно тестировать? Как определить середину?
    #39802082
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ОзверинОдна вариация: пишется тест и он не компилируется. Потом добавляется интерфейс и методы(которые не компилируются), а потом все это обрастает логикой(имплементацией).

Другая вариация: есть некое ядро разрабов-архитекторов, которые создают "скелет" приложения исключительно из интерфейсов, а имплементацию уже спускают на tdd отдел.Первый вариант мало к чему приводитбудет означать что мы еще несколько недель будем эту нетленку рефакторить, второй выглядит более разумно (ну если у нас к описанию сценариев, API и пр. есть еще всякие разные ER- и UML-диаграммы), однако получается так, что на нашей галере есть гребцы, которых заставляют писать код используя "несколько неочевидный" подход, а есть белые надсмотрщики, которые работают совсем не по TDD
...
Рейтинг: 0 / 0
Тестирование. Что именно тестировать? Как определить середину?
    #39802097
казинак
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonalex55555Он сокращает код до двух строчек, что улучшает читаемость, а значит и понимание кода.

Хотя можно и без функционального стиля в две строчки уложить. Но вероятно, что строчки будут длиннее. А вообще однозначно лучше напрячь разработчиков на хотя бы понимание функционального стиля, что бы прочитать чужое могли, ну и может иногда своё сократить.
Здесь - самый лучший кейс - голосование внутри команды. Если команда решит что ФП стиль в данном случае
лучше то я не буду спорить. голосованием решения принимаете?
обычно, на одного синьора всегда несколько падаванов,
некомпетентость всегда победит,
количеством

или вас два с половиной человека в команде?
...
Рейтинг: 0 / 0
Тестирование. Что именно тестировать? Как определить середину?
    #39802110
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
казинакmaytonпропущено...

Здесь - самый лучший кейс - голосование внутри команды. Если команда решит что ФП стиль в данном случае
лучше то я не буду спорить. голосованием решения принимаете?
обычно, на одного синьора всегда несколько падаванов,
некомпетентость всегда победит,
количеством

или вас два с половиной человека в команде?
А все синьоры?

Мне показалось что ты слегонца потралливаешь. Не?
...
Рейтинг: 0 / 0
Тестирование. Что именно тестировать? Как определить середину?
    #39802118
казинак
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonказинакпропущено...
голосованием решения принимаете?
обычно, на одного синьора всегда несколько падаванов,
некомпетентость всегда победит,
количеством

или вас два с половиной человека в команде?
А все синьоры?

Мне показалось что ты слегонца потралливаешь. Не?
нет
непонятно как можно в технических вопросах голосовать
обычно, кто грамотней к тому и прислушаются
ну или по принципу: я начальник - ты дурак ...

хотя...
в каждом домике свои гомики,
нравится голосовать, голосуйте
...
Рейтинг: 0 / 0
Тестирование. Что именно тестировать? Как определить середину?
    #39802124
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
казинакmaytonпропущено...

А все синьоры?

Мне показалось что ты слегонца потралливаешь. Не?
нет
непонятно как можно в технических вопросах голосовать
обычно, кто грамотней к тому и прислушаются
ну или по принципу: я начальник - ты дурак ...

хотя...
в каждом домике свои гомики,
нравится голосовать, голосуйте
Твой вариант какой? Главный синьор всё решил?
...
Рейтинг: 0 / 0
Тестирование. Что именно тестировать? Как определить середину?
    #39802132
chpasha
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonГлавный синьор всё решил?
склонен согласится. можно обсудить, но решение должен принять один, самый самый, какой уж есть. голосование ничего не даст - все кругом со своим мнением, причем чем больше стаж, тем больше гонор. представь, что у тебя в команде 10 вадь и два тебя. представил? вздрогнул?
...
Рейтинг: 0 / 0
Тестирование. Что именно тестировать? Как определить середину?
    #39802137
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
chpashamaytonГлавный синьор всё решил?
склонен согласится. можно обсудить, но решение должен принять один, самый самый, какой уж есть. голосование ничего не даст - все кругом со своим мнением, причем чем больше стаж, тем больше гонор. представь, что у тебя в команде 10 вадь и два тебя. представил? вздрогнул?


неуютно
...
Рейтинг: 0 / 0
Тестирование. Что именно тестировать? Как определить середину?
    #39802141
Озверин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей ПанфиловОзверинОдна вариация: пишется тест и он не компилируется. Потом добавляется интерфейс и методы(которые не компилируются), а потом все это обрастает логикой(имплементацией).

Другая вариация: есть некое ядро разрабов-архитекторов, которые создают "скелет" приложения исключительно из интерфейсов, а имплементацию уже спускают на tdd отдел.Первый вариант мало к чему приводитбудет означать что мы еще несколько недель будем эту нетленку рефакторить, второй выглядит более разумно (ну если у нас к описанию сценариев, API и пр. есть еще всякие разные ER- и UML-диаграммы), однако получается так, что на нашей галере есть гребцы, которых заставляют писать код используя "несколько неочевидный" подход, а есть белые надсмотрщики, которые работают совсем не по TDD

второй вариант - уже давно стандарт, т.к. к текучке гребцов привыкли все, а белых господ на переправе не меняют.
...
Рейтинг: 0 / 0
Тестирование. Что именно тестировать? Как определить середину?
    #39802143
казинак
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonказинакпропущено...

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

хотя...
в каждом домике свои гомики,
нравится голосовать, голосуйте
Твой вариант какой? Главный синьор всё решил?
везде так
хз чо у вас за проект такой, что вы там собираетесь и голосуете по всем проблемам
...
Рейтинг: 0 / 0
Тестирование. Что именно тестировать? Как определить середину?
    #39802173
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Озверинвторой вариант - уже давно стандарт, т.к. к текучке гребцов привыкли все, а белых господ на переправе не меняют.Прекрасно, исходя всего лишь из первого постулата TDD мы смогли определить его целевую аудиторию
...
Рейтинг: 0 / 0
Тестирование. Что именно тестировать? Как определить середину?
    #39802176
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
казинакmaytonпропущено...

Твой вариант какой? Главный синьор всё решил?
везде так
хз чо у вас за проект такой, что вы там собираетесь и голосуете по всем проблемам
Рад что у вас есть главный архитектор. Но я надеюсь что вы его не дёргаете по пустякам.
В противном случае я ему очень сочувствую.
...
Рейтинг: 0 / 0
Тестирование. Что именно тестировать? Как определить середину?
    #39802321
казинак
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonказинакпропущено...

везде так
хз чо у вас за проект такой, что вы там собираетесь и голосуете по всем проблемам
Рад что у вас есть главный архитектор. Но я надеюсь что вы его не дёргаете по пустякам.
В противном случае я ему очень сочувствую.само слово "архитектор" - это как пук в лужу
за ним ничего не стоит
только пузырьки и недолгая вонь...

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

если для вас ето слово имеет магический смысл, то сочувствую...
...
Рейтинг: 0 / 0
Тестирование. Что именно тестировать? Как определить середину?
    #39802380
vas0
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если смотреть не в вымышленный мир, а реальный. Выделенная роль архитектора, может проекту вообще ничего не дать. Не раз встречал архитекторов, которые разучились код писать. Процессы ревью кода зачастую формальность, которая не дает высокого качества кода. Тут нужно уметь критиковать и нужно уметь воспринимать критику.

Мне нравится тезис.
Проекты живут до тех пор пока код не деградирует настолько, что проект легче переписать чем поддерживать.

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

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

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

Опять же когда идет фаза сдачи релиза и код заморожен, иногда приходится рукожопить и костылить. Но такова селяви (с)
...
Рейтинг: 0 / 0
25 сообщений из 361, страница 11 из 15
Форумы / Java [игнор отключен] [закрыт для гостей] / Тестирование. Что именно тестировать? Как определить середину?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]