Является слишком большим количеством внимания на тестирование преимуществ плохая вещь в целом?

Хорошо выполненная TDD может улучшить читаемость. Плохо выполненный TDD, то есть без учета других важных принципов, может снизить удобочитаемость.

Парень, с которым я работал в середине 90-х, сказал бы: «Вы всегда можете сделать систему более гибкой, добавив уровень косвенности. всегда упрощайте систему, удаляя косвенный слой ". Гибкость и простота - важные качества системы. Эти два принципа часто могут жить вместе в гармонии, но часто они работают друг против друга. Если вы заходите слишком далеко, приближаясь к той или иной крайности, вы отходите от идеала, который существует, когда эти два принципа сбалансированы.

TDD частично касается тестирования, частично - дизайна. Плохо выполненный TDD может слишком сильно способствовать гибкости или простоте. Это может подтолкнуть к слишком большой гибкости. Объекты становятся более тестируемыми и часто более простыми, но внутренняя сложность проблемы предметной области затем вытесняется из объектов во взаимодействие объектов. Мы приобрели гибкость, и наивному глазу может показаться, что мы обрели простоту, потому что наши объекты проще. Однако сложность все еще существует. Он перемещается из объектов во взаимодействие с объектами, где его сложнее контролировать. Здесь есть запахи кода, которые могут выступать в качестве красных флажков: система с сотнями маленьких объектов и без больших объектов - это одно, множество объектов с однострочными методами - другое.

Плохо выполненный TDD может двигаться в другом направлении. а также к слишком большой простоте. Итак, мы делаем TDD, написав сначала тест, но это мало влияет на наш дизайн. У нас еще есть длинные методы и огромные объекты, и это запахи кода, которые могут указывать на эту проблему.

Теперь TDD по своей природе не выбьет вас из равновесия в любом направлении, при условии, что он правильно применяется. Используйте другие методы, чтобы не сбиться с пути. Например, перед тем как сделать это, нарисуйте то, что вы делаете. Очевидно, не всегда. Некоторые вещи для этого слишком просты. Некоторые изображения стоит сохранить, некоторые - просто наброски, которые помогают нам визуализировать проблему, и мы, в той или иной степени, в основном обучаемся визуальному восприятию. Если вы не можете нарисовать картину проблемы, значит, вы ее не понимаете.

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

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

Итак, мой ответ на ваш вопрос - «да»: протестируйте все, не забывая других хороших принципов.

«Я что-то пропустил?»

Да.

Это работает, не так ли?

И, что более важно, вы можете продемонстрировать, что это работает.

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

Альтернативы (могут работать или не работать, нет возможности продемонстрировать, работает ли это, нельзя внести изменение, не нарушив его) снижает ценность программное обеспечение до нуля.

---

Править

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

Кроме того, объективная мера сложности обычно сосредоточена на кодировании в рамках метода, а не на большей сложности отношений между классами и объектами. Сложность кажется объективной, но она не определена на всех уровнях архитектуры программного обеспечения.

«Тестируемость» также скользкая. Могут быть объективные меры проверяемости. В основном, однако, они предназначены для тестирования. А тестовое покрытие - не очень значимая метрика. Как вероятность сбоя в производственной среде зависит от покрытия тестами? Это не так.

Вы можете обвинить сложность в сосредоточении внимания на проверяемости. Вы можете винить сложность во многих вещах. Если вы внимательно посмотрите на хорошо тестируемый код, то обнаружите, что он также очень гибкий, настраиваемый и адаптируемый.

Выделение "

Я видел из первых рук веб-сайты, которые прошли все модульные тесты, прошли все автоматизированные тесты интерфейса, прошли нагрузочные тесты, прошли почти все тесты, но явно и очевидно имели проблемы при просмотре человек.

Это привело к анализу кода, который обнаружил утечки памяти, проблемы с кешированием, плохой код и недостатки конструкции. Как это произошло, если использовалось более одной методологии тестирования и все тесты прошли? Ни у одного из «модулей» не было утечек памяти или проблем с кешированием, только система в целом.

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

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

На самом деле я довольно устойчив к добавлению сложности там, где я можно этого избежать. Я еще не перешел на структуру DI / IoC, например, предпочитая вручную вводить зависимости только там, где это необходимо для тестирования. С другой стороны, когда я, наконец, принял практику, которая «увеличивает» сложность - например, имитирующие фреймворки - я обнаружил, что сложность на самом деле меньше, чем я боялся, а выгода больше, чем я предполагал. Возможно, со временем я обнаружу, что это справедливо и для фреймворков DI / IoC,

«Или я что-то пропустил?»

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

Код не должен быть более сложным, чтобы его можно было лучше тестировать. Рефакторинг кода с целью сделать его более тестируемым действительно делает код более гибким и состоит из меньших частей. Это не обязательно означает более сложный (что уже является широко распространенным термином) или необходимость действий на расстоянии.

Не зная подробностей, я могу дать только общий совет. Убедитесь, что вы используете не только схему недели. Если у вас есть метод, который требует большой настройки или сложных способов переопределения его поведения, часто внутри есть ряд более простых, детерминированных методов. Извлеките эти методы, и тогда вам будет проще их тестировать.

Тесты не должны быть такими чистыми и хорошо спроектированными, как код для их тестирования. Часто лучше сделать то, что обычно было бы неприятным взломом в тесте, чем проводить полную переработку кода. Это особенно удобно при отказе от тестирования. Необходимо смоделировать сбой подключения к базе данных? Кратко замените метод connect () на метод, который всегда дает сбой. Вам нужно знать, что происходит, когда диск заполняется? Замените метод открытия файла на тот, который не работает. Некоторые языки хорошо поддерживают эту технику (Ruby, Perl), другие - не очень. То, что обычно является ужасным стилем, становится мощной техникой тестирования, прозрачной для вашего производственного кода.

Я однозначно скажу, что никогда не помещайте в производство код, который полезен только для тестирования. Что-нибудь вроде , если (ТЕСТИРОВАНИЕ) {....} правильно. Он просто загромождает код.

Преимущества этого подхода вернутся, ЕСЛИ приложение станет достаточно большим. В противном случае - это пустая трата времени. Иногда даже перетаскивание «кодирования» и следование шаблону SmartUI достаточно.

Тестируемый продукт - это продукт, который дает возможность ответить на вопросы о нем. Возможность тестирования, как и качество, многомерна и субъективна. Когда мы оцениваем продукт как (не) тестируемый, важно осознавать, что тестируемость для одного человека может быть добавлена ​​или излишне усложнена для кого-то другого.

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

Я говорю о проверяемости здесь . Джеймс Бах говорит об этом здесь .

--- Майкл Б.

(Это полностью написано с точки зрения программиста. Для получения более ориентированного на клиента ответа я бы порекомендовал ответ Майкла Болтона.)

Если приложение, которое вы пишете, имеет <10 строк кода, то да, добавление тестов значительно увеличивает сложность. Вы можете ПОСМОТРЕТЬ НА ЭТО и протестировать вручную, и, вероятно, все будет в порядке. На 100 строках, не так много, 1000 строк, не так много, 10 000 строк, 100 000 строк ... и т. Д.

Вторая ось - это изменение. Изменится ли эта база в бухте / когда-либо /? На сколько? Чем больше будет изменен код, тем более ценными будут тесты.

Итак, да, для приложения на 150 строк кода, которое представляет собой скрипт преобразования формата edi в формат edi, который выполняется в пакетном режиме это никогда не изменится, тяжелое модульное тестирование может оказаться излишним.

Как правило, для больших приложений я ' Мы обнаружили, что изменение кода для тестирования улучшает качество дизайна и API. Так что, если вы пишете что-то гораздо более крупное или разрабатываемое итеративно, и думаете, что (автоматическое) модульное тестирование имеет высокую стоимость / низкую ценность, я бы серьезно посмотрел на то, почему вы так считаете.

Одно объяснение в том, что у вашего босса зависимость от шаблонов. Другой может заключаться в том, что вы видите шаблоны и тестирование как дискуссию по принципу «все или ничего». В-третьих, код уже написан, и вы боитесь его перезаписи для проверки. Если это так, я бы предложил хирургический подход - сосредоточиться на нескольких тестах на рентабельность, которые очень быстро повышают ценность. Расширяйте свой набор тестов медленно, по мере продвижения кода. Рефакторинг шаблонов, когда вы видите ценность и простоту, а не сложность.

Так что, если вы пишете что-то гораздо более масштабное или разрабатываемое итеративно, и думаете, что (автоматическое) модульное тестирование имеет высокую стоимость / низкую ценность, я бы серьезно посмотрел на то, почему вы так считаете.

Одно объяснение в том, что у вашего босса зависимость от шаблонов. Другой может заключаться в том, что вы видите шаблоны и тестирование как дискуссию по принципу «все или ничего». В-третьих, код уже написан, и вы боитесь его перезаписи для проверки. Если это так, я бы предложил хирургический подход - сосредоточиться на нескольких тестах на рентабельность, которые очень быстро повышают ценность. Расширяйте свой набор тестов медленно, по мере продвижения кода. Рефакторинг шаблонов, когда вы видите ценность и простоту, а не сложность.

Так что, если вы пишете что-то гораздо более масштабное или разрабатываемое итеративно, и думаете, что (автоматическое) модульное тестирование имеет высокую стоимость / низкую ценность, я бы серьезно посмотрел на то, почему вы так считаете.

Одно объяснение в том, что у вашего босса зависимость от шаблонов. Другой может заключаться в том, что вы видите шаблоны и тестирование как дискуссию по принципу «все или ничего». В-третьих, код уже написан, и вы боитесь его перезаписи для проверки. Если это так, я бы предложил хирургический подход - сосредоточиться на нескольких тестах на рентабельность, которые очень быстро повышают ценность. Расширяйте свой набор тестов медленно, по мере продвижения кода. Рефакторинг шаблонов, когда вы видите ценность и простоту, а не сложность.

Одно из объяснений состоит в том, что у вашего начальника зависимость от шаблонов. Другой может заключаться в том, что вы видите шаблоны и тестирование как дискуссию по принципу «все или ничего». В-третьих, код уже написан, и вы боитесь его перезаписи для проверки. Если это так, я бы предложил хирургический подход - сосредоточиться на нескольких тестах на рентабельность, которые очень быстро повышают ценность. Расширяйте свой набор тестов медленно, по мере продвижения кода. Рефакторинг шаблонов, когда вы видите ценность и простоту, а не сложность.

Одно из объяснений состоит в том, что у вашего начальника зависимость от шаблонов. Другой может заключаться в том, что вы видите шаблоны и тестирование как дискуссию по принципу «все или ничего». В-третьих, код уже написан, и вы боитесь его перезаписи для проверки. Если это так, я бы предложил хирургический подход - сосредоточиться на нескольких тестах на рентабельность, которые очень быстро повышают ценность. Расширяйте свой набор тестов медленно, по мере продвижения кода. Рефакторинг шаблонов, когда вы видите ценность и простоту, а не сложность.

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

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

Судя по описанию, проект потерял след YANGI, разрабатывая большие структуры, чтобы при необходимости можно было проводить тестирование.

В TDD все оправдывается тестом, поэтому факт что у вас есть все эти IoC, DI, AOP либо требовалось как простейшее решение для прохождения существующих тестов, либо (что гораздо более вероятно) чрезмерно сложное решение для сохранения тестируемого кода.

Одна ошибка, которую я видел, К такому усложнению приводит желание, чтобы тестирование следовало дизайну, а не наоборот. Может случиться так, что желание придерживаться определенного сложного для тестирования дизайна приведет к введению всевозможных обходных путей для открытия API вместо разработки более простого и легкого для тестирования API.

For better or worse TDD has helped me break down my applications into more manageable components where my ability to test items in isolation has forced me to keep things concise. The tests have also served as a good source of documentation when I introduce others to my code. Going through the tests can be a good way to review the workings of an application in where things are isolated sufficiently so you can wrap your head around the functional parts. Another nice by product is that when you have employed a design pattern in an application, the tests have a similarity to other applications where you have used that pattern.

All that said, it would be really silly to implement let's say the Command Pattern and only have two commands when you know that the app will only ever execute two functions. Now you have saddled yourself with writing a bunch of tests. What was gained? You can always test public methods, but with a pattern in place you have complexity to deal with, and have incurred technical debt with all the additional test you have to maintain.

Another factor to take into consideration is what level architecture your team can support. Are all team members at the same level of understanding of TDD, or will there be a minority of people who can understand the tests? Will seeing a mock object make someone's eyes glaze over, and does that alone become the prohibitive factor for not completing maintenance in a timely manner?

In the end, the scope of application needs to drive the design as well. Complexity for the sake of being "pure" is not good judgment. TDD does not cause this; rather, a lack of experience can.

I have no idea what you mean by it being barely readable, as, even when using AOP and DI each part should be easy to understand. Understanding the whole may be more complicated, due to these technologies, but that is more a matter of being able to explain, either with models or text, how the application works.

I am currently working on an application where there is not a single unit test, so, now I am starting to introduce DI to help make testing simpler, but, it will make it harder for the other developers to understand the system, since different concrete classes can be plugged in, and you won't know which one is until you look at the app.config file.

This could lead to them thinking the code is unreadable because they can't just flow from one function level to another easily, but have to make a side trip to see which concrete class to use.

But, in the long run this will be a more flexible and stable system, so I think it is worth the fact that some training will be involved. :)

You may just need to see about getting a better system model for the application, to see how everything is tied together.

Я просматриваю очень сложный приложение, сделанное благодаря широкому использованию шаблонов проектирования, которые чрезмерно благоприятствуют тестирование, например, IoC, DI, AOP и т. д.

В этом случае проблема не в тестировании, а в шаблонах проектирования и общей архитектуре, что часто критикуется Джоэлом и Джефф в дискуссиях против архитектурных астронавтов. Здесь у нас есть кое-что, что было решено на основе «вау крутой архитектуры», и если 1 шаблон проектирования хорош, 2 должны быть отличными, а 3 - фантастическими - давайте посмотрим, из скольких шаблонов мы можем создать это приложение.

Если тестирование, возможно, необходимо для обеспечения надежной работы этих шаблонов (хм, действительно кое-что о них говорит), но вы не должны путать хорошее тестирование с плохим архитектурным дизайном.

Итак, нет, не стесняйтесь сосредоточиться на тестировании, не беспокоясь - например, Extreme Programming - это очень простая методология разработки, ориентированная на тестирование