Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 5 6 7 8 9 [10] 11 12 13 14 15   вперед  Ctrl
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
Sergunka
Member

Откуда:
Сообщений: 1855
chpasha
Sergunka
о маентабилити

дружище, соберись, невозможно подобное читать


Ага блин... чего это я

Maintainable code is code that exhibits high cohesion and low coupling. Cohesion is a measure of how related, readable and understandable code is. ... Maintainability is itself a measure of the ease to modify code, higher maintainability means less time to make a change.
12 апр 19, 19:55    [21860848]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
mayton
Member

Откуда: loopback
Сообщений: 41056
казинак
mayton
Это противоречит современным (подтверждённым!) практикам Java-разработки и я сделал предположение
что ты с этой (Java) разработкой не знаком. Или был может быть когда-то знаком....

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

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

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

кто прав?
наверно майтон

Они оба правы. И кайт. И создатели фейсбук.

Вот такой вот парадокс. Ты согласен?
12 апр 19, 21:15    [21860891]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
alex55555
Member

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

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

В общем - хорошо, что вы там для сейлов пишете, а не для контроллеров, управляющих движками.
13 апр 19, 11:51    [21861075]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
казинак
Member

Откуда:
Сообщений: 1263
mayton
казинак
пропущено...

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

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

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

кто прав?
наверно майтон

Они оба правы. И кайт. И создатели фейсбук.

Вот такой вот парадокс. Ты согласен?

говорю же: самостоятельно мыслить не умеешь
только авторитетов поддерживаешь...
причем всех...
даже если они противоположные мнения отстаивают
ярко выраженный конформист
13 апр 19, 13:11    [21861130]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
mayton
Member

Откуда: loopback
Сообщений: 41056
казинак
mayton
пропущено...

Они оба правы. И кайт. И создатели фейсбук.

Вот такой вот парадокс. Ты согласен?

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

Так что. Можно фейсбук на Оракле построить? Не спеши с ответом. Подумай.
13 апр 19, 14:17    [21861159]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38643
казинак,
ты чего развоевался?
Причем на пустом месте.
Кайта на сегодня цитируют только в узкой среде ДБА и ветки форума Оракле.
Это не значит что он плохой или хороший.
Мысль по сабжу то твоя какая? ))
13 апр 19, 14:17    [21861161]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
Sergunka
Member

Откуда:
Сообщений: 1855
alex55555
Sergunka
Поверьте есть места где занимаются разработкой с нуля, там рефакторинг практически происходит ежедневно, так как разработчики думают о маентабилити этого кода в будущем.

Ежедневный рефакторинг - явный признак отсутствия архитектора. Когда архитектурой занимается непонятно кто, софт выходит "как всегда".


Это основа экстремального программирования где считается если тесты прошли значит ничего плохого не произошло. Понятно, что архитектурный рефакторинг согласовывается между командами, но когда во время спринта пишешь свою фичу и нужно добавить в интерфейс новый метод, то никто не будет ради этого созывать дизайн сесиию.
13 апр 19, 18:27    [21861217]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
Sergunka
Member

Откуда:
Сообщений: 1855
Petro123
казинак,
ты чего развоевался?
Причем на пустом месте.
Кайта на сегодня цитируют только в узкой среде ДБА и ветки форума Оракле.
Это не значит что он плохой или хороший.
Мысль по сабжу то твоя какая? ))


Да ладно так вообще всех распугаем... ты его еще пример теста привести попроси
13 апр 19, 18:29    [21861219]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
alex55555
Member

Откуда:
Сообщений: 2129
Sergunka
но когда во время спринта пишешь свою фичу и нужно добавить в интерфейс новый метод, то никто не будет ради этого созывать дизайн сесиию.

Обычно свой метод пишется при наличии желания со стороны заказчика. Но некоторые мне тут пытались доказать, что они рефакторят код и это им даёт изменения каждый день, без желания заказчика.

И да, зная программистов, я уверен - никто у вас там не рефакторит просто так. Только когда жаренный петух клюнет. Но если (не по моим словам) рефакторят каждый день, значит постоянно в ситуации пожара. Прекрасная работа!
14 апр 19, 13:10    [21861529]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
Sergunka
Member

Откуда:
Сообщений: 1855
alex55555
Sergunka
но когда во время спринта пишешь свою фичу и нужно добавить в интерфейс новый метод, то никто не будет ради этого созывать дизайн сесиию.

Обычно свой метод пишется при наличии желания со стороны заказчика. Но некоторые мне тут пытались доказать, что они рефакторят код и это им даёт изменения каждый день, без желания заказчика.

И да, зная программистов, я уверен - никто у вас там не рефакторит просто так. Только когда жаренный петух клюнет. Но если (не по моим словам) рефакторят каждый день, значит постоянно в ситуации пожара. Прекрасная работа!


Я же Вам объяснил я пишу продукт в команде с нуля. Когда продукт выйдет в продакшин тогда согласен это будет отдельный разговор с заказчиком если это Java EE application. Но это не мой случай когда пишется сервис там пользователей десятки тысяч физически не с кем согласовывать. Product Owner решает будет фича или нет и там уже дальше как я сказал.

Вы путаете суппорт легаси кода для Enterprise apps с разработкой сервисов там разные подходы собственно говоря спасибо так как это многое объясняет в этом топике.
14 апр 19, 20:25    [21861706]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
mayton
Member

Откуда: loopback
Сообщений: 41056
alex55555
Sergunka
но когда во время спринта пишешь свою фичу и нужно добавить в интерфейс новый метод, то никто не будет ради этого созывать дизайн сесиию.

Обычно свой метод пишется при наличии желания со стороны заказчика. Но некоторые мне тут пытались доказать, что они рефакторят код и это им даёт изменения каждый день, без желания заказчика.

И да, зная программистов, я уверен - никто у вас там не рефакторит просто так. Только когда жаренный петух клюнет. Но если (не по моим словам) рефакторят каждый день, значит постоянно в ситуации пожара. Прекрасная работа!

Рефакторинг - это просто правила хорошего тона в обществе. Это как не плевать на пол и не кидать бумажки.
Разумеется заказчик за это не платит. Это чисто - ответственность самой команды перед будущими бизнес-вызовами.
Тут вобщем если вы никогда не делаете Р. то никто вас не обвинит явно. Просто накопление технического долга
будет идти по экспоненте и рано или поздно вы почувствуете что такое не платить по счетам. Вобщем-то
термин technical dept очень хорошо отражает ситуацию.
14 апр 19, 21:21    [21861739]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
alex55555
Member

Откуда:
Сообщений: 2129
mayton
Рефакторинг - это просто правила хорошего тона в обществе.

Если люди пишут с нуля и каждый день рефакторят - что-то не так в консерватории.
15 апр 19, 12:13    [21862256]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
mayton
Member

Откуда: loopback
Сообщений: 41056
alex55555
mayton
Рефакторинг - это просто правила хорошего тона в обществе.

Если люди пишут с нуля и каждый день рефакторят - что-то не так в консерватории.

Я не говорил что рефакторят каждый день. Собственно сама задача рефакторинга
не имеет оценочного business-value. Собственно это минимизация рисков усложнения
при будущих CR.

Если вы работаете по другой модели (может гос-контора, может авиа-космос) - то прошу вас!

Расскажите как вы там работаете? Как проектируете? Как вы пишете код? Сколько
времени вы его пишете? Вобщем... как устроен у вас полный цикл?
15 апр 19, 13:39    [21862469]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3250
mayton
Я не говорил что рефакторят каждый день. Собственно сама задача рефакторинга
не имеет оценочного business-value. Собственно это минимизация рисков усложнения
при будущих CR.
У вашего же Фалера написано когда нужно делать рефакторинг:
- когда не производится ревью коданепонятно как работает код
- когда нет архитетекторавнезапно возникают новые требования
15 апр 19, 14:03    [21862504]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
mayton
Member

Откуда: loopback
Сообщений: 41056
Будет вам... Он такой-же наш как и ваш...
15 апр 19, 16:07    [21862712]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3250
mayton
Будет вам... Он такой-же наш как и ваш...
Вы можете написать когда нужно делать рефакторинг? А то мнения расходятся - вот второй сумасшедший Мартин пишет что рефакторингом нужно заниматься после каждого мочеиспускания (перевод неточный - старался смысл наиболее полно передать):
Uncle Bob Martin
The word “refactoring” should never appear in a schedule. Refactoring is not a story or a backlog item. Refactoring is not a scheduled task. Refactoring is immediate and continuous. It’s like washing your hands in the bathroom. You always do it.
И эту концепцию я вообще понять не могу: сидишь себе спокойно, пилишь фичурефакторишь, тут тебе в багтрекинт прилетает мега-срочная бага с одной из семи сред, со всякими стректрейсами, шагами воспроизведения и пр. - начинаешь смотреть в код, а в коде нихрена таких классов и методов нет - уже все отрефакторили
15 апр 19, 20:18    [21862973]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
mayton
Member

Откуда: loopback
Сообщений: 41056
Андрей Панфилов
mayton
Будет вам... Он такой-же наш как и ваш...
Вы можете написать когда нужно делать рефакторинг? А то мнения расходятся - вот второй сумасшедший Мартин пишет что рефакторингом нужно заниматься после каждого мочеиспускания (перевод неточный - старался смысл наиболее полно передать):
Uncle Bob Martin
The word “refactoring” should never appear in a schedule. Refactoring is not a story or a backlog item. Refactoring is not a scheduled task. Refactoring is immediate and continuous. It’s like washing your hands in the bathroom. You always do it.
И эту концепцию я вообще понять не могу: сидишь себе спокойно, пилишь фичурефакторишь, тут тебе в багтрекинт прилетает мега-срочная бага с одной из семи сред, со всякими стректрейсами, шагами воспроизведения и пр. - начинаешь смотреть в код, а в коде нихрена таких классов и методов нет - уже все отрефакторили

В нашей команде вопрос о рефакторинге может поставить любой разработчик.
Решаем и оцениваем командой. Обычно 99% мы заинтересованы в быстрой
поддержке кода поэтому в большинстве случаев все согласны с необходимостью.

Резкого неприятия или каких-то особо резких выступлений "против" не было.
Заводить или не заводить стори в бэклоге - решаем ситуативно. Обычно (99%)
рефакторинг связан с текущей разработкой и проводится и тестируется
в скоупе задач спринта.

Положительный поинт - перед рефакторингом обычно смотрим code-coverage.
И если где-то есть непокрытие - фиксим. И только после этого рефакторим.

Когда рефакторинг не делается.
- во времая code-freeze, когда фиксится только баг.
15 апр 19, 20:33    [21862987]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3250
mayton, вы же на вопрос не ответили... давайте в вашем сообщении заменим слово "рефакторинг" фразой "вызвать шлюх", при этом связность текста не потеряется:
mayton
В нашей команде вопрос о вызове шлюх может поставить любой разработчик.
Решаем и оцениваем командой. Обычно 99% мы заинтересованы в быстрой
поддержке кода поэтому в большинстве случаев все согласны с необходимостью.

Резкого неприятия или каких-то особо резких выступлений "против" не было.
Заводить или не заводить стори в бэклоге - решаем ситуативно. Обычно (99%)
вызов шлюх связан с текущей разработкой и проводится и тестируется
в скоупе задач спринта.

Положительный поинт - перед вызовом шлюх обычно смотрим code-coverage.
И если где-то есть непокрытие - фиксим. И только после этого вызываем.

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

Вот вы пишите про некий техдолг, который имеет свойство накапливаться и т.п., накапливается он только по двум причинам:
- кто-то лажает с code review - никакие рефакторинги здесь уже не помогут
- поджимают сроки - здесь вообще нет никаких препятствий прямо с code review завести CR на переделку фичи - оно сразу будет учтено где нужно
15 апр 19, 20:55    [21863003]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
mayton
Member

Откуда: loopback
Сообщений: 41056
Андрей Панфилов
- кто-то лажает с code review - никакие рефакторинги здесь уже не помогут
- поджимают сроки - здесь вообще нет никаких препятствий прямо с code review завести CR на переделку фичи - оно сразу будет учтено где нужно

По поводу кого-то.

Вы-же понимаете что программный продукт - это плод коллективной разработки.
И блеймить кого-то или наказывать - не стоит такая задача. Code-review обычно
делает обычный человек. И он тоже может быть уставшим. Озабоченным своей
работой и так далее. Выделенной позиции или должности на это нету.

По поводу лажает.

В лучших традициях процесса - замечания по code-review носят не директивный а
рекомендательный характер. Я взял это на вооружение и всегда пишу начиная
с : "What about... ", "Is it possible to...". Вобщем это обычный сухой технический диалог.
Я не скажу - чувак - ты облажался. Я скажу - в этом коде есть проблема. И ее
надо как-то решать.

Нельзя в команде говорить что кто-то лажает. Кто-то лажает - это поинт чтобы забить
встречу в переговоке 1+1 и обсуждать личность человека и его карьеру.
15 апр 19, 21:09    [21863011]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3250
mayton,

чет жесть какая-то, вот вы утверждаете: "Рефакторинг - это просто правила хорошего тона в обществе. Это как не плевать на пол и не кидать бумажки", если рефакторинг такой полезный, то должны существовать какие-то критерии, определяющие когда его нужно делать, и способ оценки этой "полезности", про полезность я вас пока не спрашиваю: вы пишите, что с "продажей" рефакторинга заказчику возникают проблемы, а в таком случае, вы это мне точно не сможете продать, я пока спрашиваю о том, когда нужно делать рефакторинг (мнение же идолов разнятся: один пишет что нужно 10 раз в день делать, второй, что когда в проекте появляются некие "непреодолимые препятствия" - при этом предпосылки обоих мне совершенно понятны: книжек из одной страницы с единственной фразой "дебилы, наймите себе наконец-то архитектора и делайте ревью кода" много не продашь, поэтому приходится лить воду как только можно, ну а потом, естественно, продавать консалтинг дятлам, которые не в состоянии прочесть и понять прочитанное). Причем что самое удивительное, что куда более разумную и логичную идею "лучше не пропускать плохой код, чем потом рефакторить", которая в буквальном смысле соответствует вашему "это как не плевать на пол и не кидать бумажки", вы полностью отвергаете - где здесь логика?

Вот давайте вернемся к злополучному коду от маэстро BDD:

@Then("^a list of countries should be returned _ADS_$")
public void a_list_of_counries_should_be_returned__ADS_(List<String> countries) throws Throwable {
	Set<String> set = new HashSet<String>();
	Set<String> set1 = new HashSet<String>(countries);
	for (Country c : this.countries) set.add(c.getName());
	Assert.isTrue(set.containsAll(set1));
}

как по мне, так здесь очевидно, что такой код пропускать нельзя, для этого даже не нужно смотреть что он на самом деле делает - у него просто отвратительная конвенция наименования, т.е. взгляд ревьювера здесь должен цепляться не за "Assert.isTrue(set.containsAll(set1))", а за "set" и "set1" - просто пишем что код плохой, без всяких объяснений и идем дальше - для ревьювера это дело пары секунд, даже вникать не нужно в то что происходит в коде, как только автор кода заменит эти "set" и "set1" на "returned" и "expected", то сразу же будет видна ошибка "Assert.isTrue(returned.containsAll(expected))" - это еще пара секунд без прикладывания каких-либо умственных усилий. Теперь давайте представим, что ваши замечания к коду несут рекомендательный характер, что это значит? Означает это следующее: после того как вы спалили плохую конвенцию "set" и "set1", вам нужно двигаться дальше и пытаться понять что именно там происходит, в конкретном примере все довольно просто (хотя некоторые индивидуумы уже здесь не справляются), однако если код более-менее сложный, то вам придется как минимум выписать его себе и уже смотреть в IDE (погуглите почему, к примеру, Торвальдс постоянно обоссывает плюсы - основной пойт в том, что невозможно понять изменения основываясь на одном лишь дифе файлов, та же беда с жавой) - получается так, что там где можно было просто взять и потратить на ревью кода 10 секунд, мы будем тратить полчаса, а потом еще и рефакторить - это глупость.

Дополнительный вопрос: сколько стоит поправить плохую naming convention, с учетом что у нас бывает рефлексия, сериализация, БД, внешние системы и т.д.?

Едем дальше, вот мое видение на то, как тот же тест должен выглядеть:

	assertThat(countryList, hasSize(expectedNames.size()));
	assertThat(countryList, contains(HamcrestDemo::aCountryNamed, expectedNames));

Я искренне надеюсь, что не нужно объяснять почему один код лучше другого, то вот же проблема: если у вас "рефакторинг" продуктового кода вызывает некие проблемы с обоснованием необходимости, то что тогда будет происходить с кодом тестов? Я так понимаю что для поклонников [TB]DD такое вообще невообразимо: как же так, мы тестовые сценарии ставим во главу разработки, а они оказывается полная хрень.

Эпикриз: техдолг возникает не сам по себе, а потому что это кто-то допускает.
16 апр 19, 07:16    [21863186]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5183
Андрей Панфилов, не могу не согласиться со всем выше изложенным, но у проектов:
а) бывают сжатые сроки
б) ошибки допускают все, причем включая архитекторов
в) на всех хороших специалистов не напасешься
г) есть стартапы, где "команды" толком нет

Всякие TDD и подобные - это быстрый старт в условиях фриланса и\или удаленки, когда business value выкатывают каждую неделю, тыркают кнопочки и продолжают. Да, в таких условиях(а,б,в и прочие - нужные несколько подчеркнуть) ценностью является сам продукт, а технический долг оставляют на потом, если взлетит. И да, очень часто, бывает критично важно выпустить продукт, чтобы им начали пользоваться, а потом уже решать проблемы по мере их поступления.
16 апр 19, 08:38    [21863227]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3250
Озверин,

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

Поймите простую вещь: то что пишут в книжках, оно априори рассчитано на текущую конъюнктуру - иначе книжку не продать, другими словами эти книжки рассчитаны на команды, в которых бОльшая часть разработчиков - люди, с несколько более смуглым оттенком кожи чем ваш, и в таких командах рубить говнокод на корню довольно плохая затея, потому что завтра вам попадется негр-трансвестит, который будет утверждать, что его код зарубили только из-за его мировоззрения (тесты-то все зеленые!), в следствие чего одни понятия (код изначально должен быть хорошим) заменяются другими (весь код плохой, поэтому нужно его постоянно рефакторить) - это неправильно, рекомендую вам купить любую такую книжку, потом сжечь, обоссать и выкинуть.
16 апр 19, 10:21    [21863347]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5183
Андрей Панфилов, я пишу о том, что не бывает проектов(а если они и есть, я ни разу их не видел), где не было б технического долга вовсе. А раз таких проектов нет, то ценность совета: просто все сделайте правильно и рефакторинг не нужен будет - падает на порядок ниже советов вроде: как писать код, чтобы его потом можно было б отрефакторить в сжатые сроки.

Другими словами, от "рефакторить" никуда не деться, а значит:

[Андрей Панфиловкнижек из одной страницы с единственной фразой "дебилы, наймите себе наконец-то архитектора и делайте ревью кода" много не продашь[/quote]

работает, ну мягко говоря, даже не в 10% случаев.
16 апр 19, 10:36    [21863368]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5183
Андрей Панфилов, я пишу о том, что не бывает проектов(а если они и есть, я ни разу их не видел), где не было б технического долга вовсе. А раз таких проектов нет, то ценность совета: просто все сделайте правильно и рефакторинг не нужен будет - падает на порядок ниже советов вроде: как писать код, чтобы его потом можно было б отрефакторить в сжатые сроки.

Другими словами, от "рефакторить" никуда не деться, а значит:

Андрей Панфилов
книжек из одной страницы с единственной фразой "дебилы, наймите себе наконец-то архитектора и делайте ревью кода" много не продашь


работает, ну мягко говоря, даже не в 10% случаев.
16 апр 19, 10:37    [21863372]     Ответить | Цитировать Сообщить модератору
 Re: Тестирование. Что именно тестировать? Как определить середину?  [new]
mayton
Member

Откуда: loopback
Сообщений: 41056
Андрей Панфилов
Едем дальше, вот мое видение на то, как тот же тест должен выглядеть:

	assertThat(countryList, hasSize(expectedNames.size()));
	assertThat(countryList, contains(HamcrestDemo::aCountryNamed, expectedNames));


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

Я-бы оставил тест как есть в первом варианте. При прочих равных условиях если стоит
вопрос менять или не менять тест я выбираю - не менять. Тест - это закон. Закон по которому
должен работать код. И надо иметь очень много освнований чтоб менять сам тест.
16 апр 19, 10:51    [21863393]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 5 6 7 8 9 [10] 11 12 13 14 15   вперед  Ctrl
Все форумы / Java Ответить