S>>За исключением тех случаев, когда эти 100% действительно нужны. I>Это не добавляет качества, а количество работы удесятеряет. Стоит покрывать не строчки кода, а ключевые кейсы. Здесь проценты не зафиксируешь, зато эффекта будет гораздо больше. I>Нужно понимать, что 100% это всего лишь про строчки, а не ветвления.
А разве в 100% ветвления не входят?
I>То есть, покрыв 100% строчек можно нисколечко не приблизиться к покрытию основных кейсов. I>Считать ветвления еще не научились, а простой подсчет говорит о том, что покрытие ветвлений требует астрономическое количество тестов.
По-моему, научились. Там этих метрих для покрытия кода чуть ли не 3, и одна из них про ветвления.
I>Зато покрытие основных кейсов вполне может дать покрытие 80% строчек. Остальное покроется тестами верхнего уровня, тестами на стейджинге и тд.
Я не против, но такое ощущение что путаете разработку сайта или какого продукта или сервиса по аджайл с разработкой
марсохода у НАСА. Это совершенно два разных мира, и если где-то 100% действительно не нужно ибо долго и дорого, а надо фичи
пилить, то где-то без 100% покрытия шагу не сделают. О чем тут спор тогда?
Здравствуйте, Sharov, Вы писали:
I>>Это не добавляет качества, а количество работы удесятеряет. Стоит покрывать не строчки кода, а ключевые кейсы. Здесь проценты не зафиксируешь, зато эффекта будет гораздо больше. I>>Нужно понимать, что 100% это всего лишь про строчки, а не ветвления.
S>А разве в 100% ветвления не входят?
Очевидно, нет — для 100% ветвлений нужно астрономическое число тестом. См. Искусство тестирования, Гленфорд Майерс
I>>Считать ветвления еще не научились, а простой подсчет говорит о том, что покрытие ветвлений требует астрономическое количество тестов.
S>По-моему, научились. Там этих метрих для покрытия кода чуть ли не 3, и одна из них про ветвления.
См. книгу выше. S>Я не против, но такое ощущение что путаете разработку сайта или какого продукта или сервиса по аджайл с разработкой S>марсохода у НАСА. Это совершенно два разных мира, и если где-то 100% действительно не нужно ибо долго и дорого, а надо фичи S>пилить, то где-то без 100% покрытия шагу не сделают. О чем тут спор тогда?
А не надо сюда наса тянуть, это единичные проекты. И даже там нет смысла гнаться за строчками и прочими глупыми КПИ. Внятный код-ревью экономит годы разработки даже в наса.
Еще раз
— 100% строчек могут нисколько не покрыть кейсы, компоненты могут валиться, а все тесты будут зелеными
— 100% ветвлений это астрономическое число тестов
Именно по этой причине используются разные методы одновременно.
The cyclomatic complexity of a section of source code is the maximum number of linearly independent paths within it—where "linearly independent" means that each path has at least one edge that is not in one of the other paths.
То есть, это не все пути/ветвления, а только некоторая часть. Более того, нас интересуют большей частью скрытые ветвления, который в силу отсутствия ссылочной прозрачности выявить не получается.
Отсюда понятно, почему бОльшая часть инструментов про покрытие оперирует строчками.
Здравствуйте, Sharov, Вы писали:
I>>Нужно понимать, что 100% это всего лишь про строчки, а не ветвления. S>А разве в 100% ветвления не входят?
Вот такой код:
void f(int i) {
var list = new ArrayList<String>();
if(i % 2 == 0) list.add("hi");
if(i % 3 == 0) list.add("bye");
use(list);
}
покрывается на 100% по ветвлениям тестами f(2) и f(3). Но никак не тестируются ситуации, когда list пустой, например.
Так что покрытие ветвлений — этого мало. Надо ещё покрывать все пути исполнения. Но таких путей экспоненциально много, поэтому нереально.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
I>The cyclomatic complexity of a section of source code is the maximum number of linearly independent paths within it—where "linearly independent" means that each path has at least one edge that is not in one of the other paths.
I>То есть, это не все пути/ветвления, а только некоторая часть. Более того, нас интересуют большей частью скрытые ветвления, который в силу отсутствия ссылочной прозрачности выявить не получается. I>Отсюда понятно, почему бОльшая часть инструментов про покрытие оперирует строчками.
Ну и в догонку:
The essence of this observation is that larger programs tend to be more complex and to have more defects. Reducing the cyclomatic complexity of code is not proven to reduce the number of errors or bugs in that code.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
I>>Отсюда понятно, почему бОльшая часть инструментов про покрытие оперирует строчками. ·>Ну и в догонку: ·>
The essence of this observation is that larger programs tend to be more complex and to have more defects. Reducing the cyclomatic complexity of code is not proven to reduce the number of errors or bugs in that code.
Собственно, логично — уменьшили какую-то ничтожно малую часть всех путей. Как это повлияло на все возможные пути — не ясно, т.к. их количество исчисляется астрономическими величинами.
Единственно, что можно утверждать, это меньшая цикломатическая сложность дает более понятный для человека код, а следовательно и более управляемый.
Соответсвенно можно лучше покрыть тестами, можно лучше покрыть всякими ассертами(предусловия, постусловия и тд), легче выявить проблемы на код-ревью. Но это дополнительная работа. Без этой дополнительной работы совсем не ясно, каким образом уменьшение цикломатической сложности уменьшит количество багов.
