mfp: Late night discussions on software development #3: Unit testing

[Blog bot]

Источник: http://blogs.msdn.com/mfp/archive/20...t-testing.aspx
==============

“It is a true blessing to have lots of automated unit tests”, I say aloud trawling for a response.
“It certainly is.” is the response I get back.
I throw out another statement: ”It just feels so good to have over 80% code coverage. It makes you almost invulnerable. You can change just about anything, and if the tests pass, you know you did a good job.”
“It makes you blind, is what it does.” is the unexpected answer I get back.
I look at S?ren, who is sitting quietly and comfortably in his armchair. I lean forward. “What do you mean? I feel the exact opposite of being blind – I have full transparency into my tests cases, I know exactly what parts of the code they exercise, and I know if any of them fail.”
“Tell me, why do you write unit tests?”
“To have high coverage numbers.”
“And why would you like to have high coverage numbers?”
“So I know my code is fully exercised by the unit tests.”
“And why would you like the code to be fully exercised by unit tests?”, S?ren keeps pushing.
I feel like this is a cat-after-the-mouse-chase, but I’m up to it. “So I know my code works.”
“Assuming your unit tests passed once, why do you keep them?”
“Because the code may stop working due to a change.”
“Ok, so let me ask you again: Why do you write unit tests?“
“So I know my code works at all times”, I answer.
“Or as I prefer to phrase it: ‘to prevent regressions.’ So let me ask you: How good is your protection against regressions if your code coverage is 80%?”
The answer is almost out of my mouth before I stop myself. S?ren has a point. 80% code coverage doesn’t mean 80% protection. But what does it mean? Just because a unit test exercises the code, it doesn’t mean it will detect all possible failures in the code. I’m silent; I don’t know what to reply.
After a while S?ren says: “Zero code coverage means you haven’t done enough, 100% code coverage means you don’t know what you got.”
“So why do we measure code coverage at all?”
“Because it’s easy to measure, easy to understand, and easy to fool yourself. It is like measuring the efficiency of a developer by the number of code lines he can produce. A mediocre developer writes 100 lines per hour, a good developer writes 200 lines; but a great developer only has to write 50 lines.”
I can see his point. I would never measure a developer on how many lines of code he writes.
“Tell me, how often do your unit tests fail?” S?ren asks.
“Occasionally; but really not that frequently.”
“What is the value of a unit test that never fails?”
“It ensures the code still works.”, I say feeling I'm stating the obvious.
“Are you sure? If it never fails, how will it detect the code is buggy?”
“So you are saying a unit test that never fails doesn’t add protection?”
“Yes. If it never fails, it is just hot air, blinding you from real problems, and wasting your developers’ time”.
“So we should design our unit tests to fail once in a while?”
“Yes, a unit test that truly never fails is worthless! Actually it is even worse, it is counterproductive. It took time to write, it takes time to run, and it adds no value. “
“Well, it does add the value that the code has been exercised.”
“I have seen unit tests without a single assert statement. Yes, it certainly exercises some code, but unless the code crashes it offers no protection.”
“Why would anyone write a unit test without assert statements?”
“To get the high code coverage numbers their managers demand.”
I pour us another glass of red wine, while I’m mentally trying to grasp the consequences of what I just learned. By measuring code coverage we are actually fostering an environment where worthless unit tests are rewarded just as much as priceless unit tests. “As I see it we need to distinguish the good from the bad unit tests. Any ideas?” I ask.
“The bad unit tests come in three flavors: Those that don’t assert anything, but are solely written to achieve a code coverage bar, those that test trivial code, such as getters and setters, and those that prevent good fixes.”
“I can understand the first two, but please elaborate on the last one.”
“Suppose you write a unit test that asserts an icon in the toolbar has a certain resource ID. When the icon eventually is updated this unit test will fail. It adds no value, as the icon was supposed to be update. This means the developer has two hard coded lists to maintain when changing icons: one in the product code and one in the unit tests.”
“Got it, how would you propose a better unit test for this case?”
“Well, a unit test verifying that all icons have a valid resource ID and that no two icons share the same resource would be a good start.”
I can certainly see the difference, the latter unit test wouldn’t need updating every time an icon was changed, but it would detect problems our customers would notice. I wonder how many of our unit tests fall into these three categories. I need to find a way to reward my developers for writing good unit tests.
S?ren interrupts my chain of thought, “What do you do when a unit test fails?”
“We investigate. Sometimes it is the unit test that is broken; sometimes it is the product code that is broken.”
“Who makes that investigation?”
“The developer who has written the product code that makes the unit test fail.”
“So basically you are letting the wolf guard the sheep!”
“What do you mean?”
“If developer A writes a unit test to protect his code, and developer B comes along and breaks the code, you let developer B judge whether it is his own code or developer A’s code that is to blame. Developer A would grow quite sour if he detected that developer B was lowering the defense in the unit test to get his changes through.”
“Yes, that certainly wouldn’t be rewarding. I guess it would be much more rewarding for developer A to receive an alarm when developer B broke his test. He would then know that his test worked and he could work with developer B to resolve the issue.”
S?ren nods.
It certainly dawns on me. Writing a bad unit test wouldn’t be rewarding, as it would never fail; whereas a good unit test would eventually catch a fellow developer’s mistake. I know the developers in my team well enough to understand the level of sound competition such an alert system would cause. I set my glass on the table. I have some infrastructure changes to make on Monday.


==============
Источник: http://blogs.msdn.com/mfp/archive/20...t-testing.aspx

[kashperuk]

Кто этот Сорен интересно? Прям как мастер Йода какой-то

[Jabberwocky]

Зато он задает правильные вопросы, в которых, как известно, уже есть половина ответа.
Квинтэссенция всего Unit testing заключена в словах:
“So why do we measure code coverage at all?”
“Because it’s easy to measure, easy to understand, and easy to fool yourself."

Мощно задвинул, внушаить. (с)

[SEKL]

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

[gl00mie]

Такие вот рассуждения, как в приведенной публикации из блога, и приводят, кроме прочего, к осознанию, что программирование - это не только знание синтаксиса, определенных API/технологий и неких Best Practices, завещанных предыдущими поколениями программистов без каких-либо комментариев и разъяснений Касаемо тестирования можно вспомнить рассуждения из одной очень хорошей книги (пусть кто-то и считает, что в ней 95% воды):

Цитата:

Ограничения тестирования, выполняемого разработчиками.
Разработчкики обычно выполняют «чистые тесты». Разработчики склонны тестирвовать код на предмет того, работает ли он (чистые тесты), а не пытаться нарушить его работу всевозможными способами (грязные тесты).

возможно, это и пытался сказать S?ren, рассуждая о бесполезности и даже контрпродуктивности тестов, которые всегда проходят успешно

Цитата:

В организациях с незрелым процесом тестирования обычно выполняют около пяти чистых тестов на каждый грязный. В организациях со зрелым процессом тестирования на каждый чистый тест обычно приходится пять грязых тестов. Это отношение изменяется на противоположное не за счет снижения числа чистых тестов, а за счет создания в 25 раз большего числа грязных тестов.
Разработчики часто имеют слишком оптимистичное представление о покрытии кода тестами. Как правило, программисты считают, что они достигают 95%-го покрытия кода тестами, но на самом деле они обычно достигают в лучшем случае примерно 80%-го покрытия, в худшем - 30%-го, а в среднем - где-то на 50-60% (по данным Boris Beizer, 1990, «Software Testing Techniques», 2nd ed, NY: Van Nostradam Reinhold).
Разработчики часто упускают из виду более сложные аспекты покрытия кода тестами. Большинство разработчиков считают тип покрытия кода тестами, известный как «100%-е покрытие операторов», адекватным. Это хорошее начало, но такого покрытия едва ли достаточно. Лучший тип покрытия - так называемое «100%-е покрытие ветвей», требующее, чтобы каждой переменной каждого предиката при тестировании было присвоено хотя бы одно истинное и одно ложное значение.
Эти ограничения не уменьшают важность тестирования, выполняемого разработчиками, - они лишь помогают получить о нем более адекватное представление.

А также

Цитата:

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

Методика устранения дефектов		Минимальная	Типичная	Максимальная
					эффективность	эффективность	эффективность
Неформальные обзоры проекта		25%		35%		40%
Формальные инспекции проекта		45%		55%		65%
Неформальные обзоры кода		20%		25%		35%
Формальные инспекции кода		45%		60%		70%
Моделирование или прототипирование	35%		65%		80%
Самостоятельная проверка кода		20%		40%		60%
Блочное тестирование			15%		30%		50%
Тестирование новых функций/компонентов	20%		40%		60%
Интеграционное тестирование		25%		35%		40%
Регрессионное тестирование		15%		25%		30%
Тестирование системы			25%		40%		55%
Ограниченное бета-тестирование		25%		35%		40%
(менее чем в 10 организациях)
Крупномасштабное бета-тестирование	60%		75%		85%
(более чем в 1000 организаций)

Источники: Capers Jones, 1986, «Programming Productivity», NY: McGraw-Hill; Capers Jones, 1996, «Software Defect-Removal Efficiency», IEEE Computer; Shull, et al., 2002, «What We Have Learned About Fighting Defects», Proceedings, Metrics 2002. IEEE; 249-258.
Самое интересное в этих данных то, что типичная эффективность обнаружения дефектов при использовании любой методики не превышает 75% и что в среднем она равна примерно 40%. Более того, самые популярные методики - блочное тестирование и интеграционное тестирование - позволяют найти обычно только около 30-35% дефектов. Как правило, используется подход, основанный на интенсивном тестировании, что позволяет устранить лишь около 85% дефектов. Ведущие организации используют более широкий диапазон методик, достигая при этом 95%-ой или более высокой эффективности устранения дефектов (Capers Jones, 2000, «Software Assessments, Benchmarks, and Best Practices», Reading MA: Addison-Wasley). Итак, если разработчики хотят достигнуть более высокой эффективности обнаружения дефектов, они должны полагаться на комбинацию методик.

[gl00mie]

Цитата:

Сообщение от SEKL

В явном и простом виде измерить качество кода похоже практически невозможно. Поэтому и пытаются придумать хоть что-то. На самом же деле unit testing, на мой взгляд имеет отношение к качеству очень и очень отдаленное.

Мне кажется, тут имеет место определенное смешение понятий. Говоря о качестве, как правило, рассматривают ПО в целом, а не только код - тем же заказчикам, в конце концов, код совершенно безразличен, в то же время, им, как правило, небезразлично качество получаемого готового продукта - ПО. Среди характеристик качества ПО (если опять же вспомнить книгу, состояющую на 95% из воды) можно выделить

• корректность - отсутствие/наличие дефектов в спецификации, проекте и реализации системы
• практичность - тут можно вспомнить эргономику с ее управляемостью, обслуживаемостью, освояемостью и обитаемостью
• эффективность - степень использования системных ресурсов
• надежность - способность системы выполнять необходимые функции в предопределенных условиях; средний интервал между отказами
• целостность - способность системы предотвращать неавторизованный или некорректный доступ к своим программам или данным
• адаптируемость - возможность использования системы без ее изменения в тех областях или средах, на которые она не была ориентирована непосредственно
• правильность - степень безошибчности системы, особенно в отношении вывода количественых данных (не путать с тем, насколько корректно создана сама система)
• живучесть - способность системы продолжать работу при вводе недопустимых данных или в напряженных условиях

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

• удобство сопровождения
• гибкость
• портируемость
• возможность повторного использования
• удобочитаемость
• тестируемость

к этим характеристикам блочное тестирование действительно имеет отношение очень и очень отдаленное...

[belugin]

Цитата:

Сообщение от SEKL

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

Unit testing еще и заставляет разбивать код на модули с понятным интерфейсом. И еще играет роль документации.

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

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