История изменений

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

При непосредственном тестировании гораздо легче обеспечить полноту покрытия, и тем самым создать условия для проявления бага. А тесты клиентской функции (т.е. функции, которая пользуется данной) тогда могут быть сфокусированы на покрытии кода именно самой клиентской функции, а не на опосредованном покрытии кода её зависимостей. Вполне вероятно, что клиентскую функцию захочется тестировать не с «боевыми» зависимостями, а с моками. То есть, смысл - в снижении сложности тестов, по принципу "разделяий и властвуй".

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

Представь себе сложную схему из сотен логических элементов И-НЕ. С сотнями входов и десятками выходов. При этом некоторые выходы соединены с некоторыми входами. И как же предполагается это декомпозировать?

Предположу, что это нагромождение из булевых элементов и зацикленных входов-выходов было синтезировано исходя из некой высокоуровневой логики. Вот в соответствии с этой высокоуровневой логикой и нужно декомпозировать - на части, имеющие четкое собственное предназначение / смысл, и как можно менее многочисленные связи друг с другом. Если мы всё ещё о программном коде говорим, то можно посмотреть на декомпозицию через призму принципов SOLID.

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

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

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

При непосредственном тестировании гораздо легче обеспечить полноту покрытия, и тем самым создать условия для проявления бага. А тесты клиентской функции (т.е. функции, которая пользуется данной) тогда могут быть сфокусированы на покрытии кода именно самой клиентской функции, а не на опосредованном покрытии кода её зависимостей. Вполне вероятно, что клиентскую функцию захочется тестировать не с «боевыми» зависимостями, а с моками.

Смысл в снижении сложности тестов, по принципу "разделяий и властвуй".

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

Представь себе сложную схему из сотен логических элементов И-НЕ. С сотнями входов и десятками выходов. При этом некоторые выходы соединены с некоторыми входами. И как же предполагается это декомпозировать?

Предположу, что это нагромождение из булевых элементов и зацикленных входов-выходов было синтезировано исходя из некой высокоуровневой логики. Вот в соответствии с этой высокоуровневой логикой и нужно декомпозировать - на части, имеющие четкое собственное предназначение / смысл, и как можно менее многочисленные связи друг с другом. Если мы всё ещё о программном коде говорим, то можно посмотреть на декомпозицию через призму принципов SOLID.

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

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

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

При непосредственном тестировании гораздо легче обеспечить полноту покрытия, и тем самым создать условия для проявления бага. А тесты клиентской функции (т.е. функции, которая пользуется данной) тогда могут быть сфокусированы на покрытии кода именно самой клиентской функции, а не на опосредованном покрытии кода её зависимостей. Вполне вероятно, что клиентскую функцию захочется тестировать не с «боевыми» зависимостями, а с моками.

Смысл в снижении сложности тестов, по принципу "разделяий и властвуй".

Представь себе сложную схему из сотен логических элементов И-НЕ. С сотнями входов и десятками выходов. При этом некоторые выходы соединены с некоторыми входами. И как же предполагается это декомпозировать?

Предположу, что это нагромождение из булевых элементов и зацикленных входов-выходов было синтезировано исходя из некой высокоуровневой логики. Вот в соответствии с этой высокоуровневой логикой и нужно декомпозировать - на части, имеющие четкое собственное предназначение / смысл, и как можно менее многочисленные связи друг с другом. Если мы всё ещё о программном коде говорим, то можно посмотреть на декомпозицию через призму принципов SOLID.

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

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