Тепер я знаю, що люди могли б вважати це питання повторюваним або задавали його багато разів, і в такому випадку я буду вдячний за посилання на відповідні питання з відповіддю на моє запитання.
Я нещодавно не погоджувався з деякими людьми щодо висвітлення коду. У мене є група людей, які хочуть, щоб наша команда взагалі переглядала покриття коду, виходячи з аргументу, що 100% охоплення не означає тестів на якість та, таким чином, код хорошої якості.
Мені вдалося відштовхнутися, продаючи аргумент, що Code Coverage повідомляє мені те, що не перевірено точно, і допомагає нам зосередитися на цих областях.
(Вищезазначене обговорювалося аналогічно в інших питаннях на зразок цього - /programming/695811/pitfalls-of-code-coverage )
Аргумент цих людей полягає в тому, - тоді команда реагувала б, швидко створюючи тести низької якості і, таким чином, витрачаючи час, не додаючи значної якості.
Хоча я розумію їхню точку зору, я шукаю спосіб зробити більш надійний випадок для покриття коду, ввівши більш надійні інструменти / рамки, які беруть до уваги більш критерії покриття (Functional, Statement,Decision, Branch, Condition, State, LCSAJ, path, jump path, entry/exit, Loop, Parameter Value etc) .
Що я шукаю, - це пропозиція щодо комбінації таких інструментів для висвітлення коду та практик / процесів, які можуть допомогти мені протистояти таким аргументам, відчуваючи себе комфортно щодо моєї рекомендації.
Я також вітаю будь-які супровідні коментарі / пропозиції, засновані на вашому досвіді / знаннях щодо протидії такому аргументу, оскільки, хоча суб'єктивне, висвітлення коду допомогло моїй команді бути більш обізнаною щодо якості коду та цінності тестування.
Редагувати: Щоб зменшити будь-яку плутанину щодо мого розуміння слабкості типового покриття коду, хочу зазначити, що я не маю на увазі інструментів Statement Coverage (або рядків виконуваного коду) (є безліч). Насправді тут хороша стаття про все, що з цим не так: http://www.bullseye.com/statementCoverage.html
Я шукав більше, ніж просто покриття висловлювань чи рядків, більш детально вкладаючись у кілька критеріїв та рівнів покриття
Дивіться: http://en.wikipedia.org/wiki/Code_coverage#Coverage_criteria
Ідея полягає в тому, що якщо інструмент може повідомити нам про наше покриття на основі декількох критеріїв, це стане розумною автоматизованою оцінкою якості тесту. Я ні в якому разі не намагаюся сказати, що покриття ліній - це хороша оцінка. Насправді це передумова мого питання.
Редагувати:
Гаразд, можливо, я спроектував це трохи надто драматично, але ви розумієте. Проблема полягає у встановленні процесів / політик взагалі для всіх команд однорідним / послідовним способом. І страх загальний, як ви гарантуєте якість тестів, як виділяєте гарантований час, не маючи до цього жодних заходів. Таким чином, мені подобається мати вимірювальну особливість, яка, підкріплюючись відповідними процесами та правильними інструментами, дозволить нам покращити якість коду, знаючи, що час не витрачається на сили, що витрачаються на марнотратні процеси.
EDIT: Поки що у мене є відповіді:
- Огляди коду повинні охоплювати тести, щоб забезпечити якість тестів
- Тест Перша стратегія допомагає уникнути тестів, написаних після факту, щоб просто збільшити покриття%
- Вивчення альтернативних інструментів, які охоплюють критерії тестування, окрім просто Звернення / рядка
- Аналіз прихованого коду / кількості знайдених помилок допоможе оцінити важливість покриття та зробити кращий випадок
- Найголовніше довіряйте внеску Команди в те, щоб зробити правильно і боротися за свої переконання
- Блоки охоплені / # тестів - дискусійні, але мають деяке значення
Дякую за приголомшливі відповіді поки що. Я дуже їх ціную. Ця нитка краща за години мозкового штурму з силами, які є.