Что более важно, тестируемость кода или соблюдение принципов ООП? [закрытый]
15 ответов
ООП является всего одной парадигмой среди многих возможных. Это не цель сам по себе, это - средство для конца. Вы не должны программировать объектно-ориентированный, не, если другие парадигмы лучше подходят для Вас.
И бесчисленные умные люди, прежде чем Вы отметили, что поблочное тестирование имеет тенденцию быть намного легче на функционально-ориентированных языках, чем объектно-ориентированные, просто потому что естественная единица для теста функция. Это не класс (который может иметь закрытые методы и все виды странного состояния), но функция.
Тестируемость, с другой стороны, действительно имеет значение сам по себе. Если Ваш код не является тестируемым, Вы не можете протестировать его (очевидно), и если Вы не можете протестировать его, как можно сказать, что он работает? Таким образом, если бы необходимо выбрать одно экстремальное значение или другой, я, конечно, выбрал бы тестируемость.
, Но очевидный вопрос, необходимо ли действительно протестировать каждый закрытый метод? Они не часть государственного контракта класса и не могут быть значимыми в изоляции. Открытые методы важны для теста, потому что у них есть определенная цель, они должны выполнить этот очень определенный контракт и оставить объект в согласованном состоянии и так далее. Они являются по сути тестируемыми, способом что закрытый метод не может быть. (Кто заботится о том, что делает закрытый метод? Это не часть контракта класса)
, Возможно, лучшее решение состояло бы в том, чтобы просто осуществить рефакторинг часть в других отношениях частного материала в отдельные классы. Возможно, потребность в тестировании закрытых методов не является столь большой, как Вы думали.
На другой ноте, другие платформы насмешки действительно позволяют Вам дразнить частный материал также.
Редактирование: После размышления об этом немного далее, я хотел бы подчеркнуть, что просто обнародовать членов парламента, не занимающих официального поста является, вероятно, ужасной идеей. Причина у нас есть члены парламента, не занимающие официального поста во-первых, является этим: инвариант класса должен сохраняться в любом случае. Для внешнего кода должно быть невозможно принести Ваш класс в недопустимое состояние. Это не просто ООП, это - также здравый смысл. Закрытые методы состоят в том, чтобы просто позволить Вам более прекрасную гранулярность внутренне в классе, факторизовав некоторые задачи через несколько методов и такой, но они обычно не делают , сохраняют инвариант класса. Они делают половину задания и затем полагаются на некоторый другой закрытый метод, называемый впоследствии, чтобы сделать другую половину. И это безопасно, потому что они не обычно доступны. Только другие методы класса могут назвать их, поэтому, пока они сохраняют инвариант, все хорошо.
Поэтому да, при создании закрытых методов тестируемыми путем превращения их общедоступный Вы также представляете источник ошибок, которые могут не быть пойманными легко модульными тестами. Вы позволяете использовать класс "неправильно". Хорошо разработанный класс всегда поддерживает свой инвариант, неважно, как он используется внешним кодом. После того как Вы обнародовали все, которое больше не возможно. Внешний код может вызвать внутренние функции помощника, которые не могут использоваться в том контексте, и которые бросят класс в недопустимое состояние.
И модульные тесты не может действительно гарантировать, что этого не происходит. Таким образом, я сказал бы, что Вы рискуете представлять намного больший источник ошибок, чем Вы, возможно, ожидали.
, Конечно, учитывая это выше определения членов парламента, не занимающих официального поста (те, которые не сохраняют инвариант класса), могло бы быть возможно безопасно повернуть много другой общественности методов, потому что они делают , сохраняют инвариант, и таким образом, нет никакой потребности скрыть их от внешнего кода. Так, чтобы мог бы сделать, уменьшают Вашу проблему, путем предоставления Вам меньше закрытые методы, но не позволяя внешнему коду повредить Ваш класс, как было бы возможно, если бы все было общедоступно.
Почему Вы не можете использовать друга классы, которые являются только тестовыми классами? Кроме того, Ваши тестовые классы происходят из родительских классов, которые имеют членов парламента, не занимающих официального поста.
Обнародовать все для угождения плохим инструментам тестирования является ошибкой, по-моему. Как другие сказали - этому не придется быть выбором. Разработайте хорошее программное обеспечение. Тест хорошо и использует хорошие инструменты. Если необходимо повредить известные лучшие практики для некоторого инструмента тестирования затем, пора заново продумать инструмент тестирования...
Почему не только используют макрос вместо частного ключевого слова. Когда Вы компилируете с "testmode" на, те методы открыты. Иначе они являются частными. С макросом Вы все еще получите предупреждения компилятора при использовании закрытых методов публично после того как Вы компилируете не в режиме тестирования. Интересно отметить, что наличие Ваших закрытых методов перестало работать, их модульные тесты не подразумевает ошибку в Вашей программе, хотя это, вероятно, эквивалентно наличию функции, "CauseBSOD", который никогда не называют. Это - в большой степени поврежденная функция (предполагающий, что порождение BSOD's не предназначается), но это не ошибка, что касается пользователей.
Как обычный пользователь Intellisense, требование, чтобы все методы быть общедоступными управляли бы мной безумный. Я придерживался бы ООП на одной только той основе, лично.
Я не знаком ни с каким конфликтом между ними всеми. Высокосвязная и слабая связь является ядром OO, и это, оказывается, ядро тестирования также.
Относительно объема классов Вы могли использовать внутренности, чтобы упростить платформу (для конечных пользователей) и указать в AssemblyInfo.cs
[assembly: InternalsVisibleTo("MyAssembly.Tests")]Я использую Насмешки Носорога, и я использую много закрытых методов. Я обычно пишу свои классы для зависимости от интерфейсов, а не других классов, потому что это делает насмешку легче.
Если существует платформа, которая ограничивает меня в использовании чего-то как закрытые методы, я отбрасываю его. Период. Это - одна из тех фундаментальных вещей на большинстве языков, это необходимо.
Внедрение зависимости & Инверсия Управления является довольно хорошими способами получить лучший из обоих миров. Хороший дизайн не должен ограничивать Вашу способность использовать код по-разному (тест), это должно улучшить его.
Мы переписываем целый набор одиночных элементов для использования DI/МОК прямо сейчас так, чтобы мы могли протестировать их (прибывающий скоро в кабельную муфту около Вас).
Хороший дизайн OO является больше, чем инкапсуляция, больше, чем наличие закрытых методов.
Один из главных запахов дизайна связывается между различными частями системы. Перед введением классов помощника в объекты протестировать их как объекты получали доступ к помощникам?
Мое предположение - то, что путем переключения на внедрение зависимости Вы понизили связь в своей системе.
существует также эти , Открываются/Закрывают принцип . Путем введения классов помощника Вы позволяете полиморфную замену поведения.
И если существует некоторая озабоченность по поводу наличия незакрытых методов, видимых на классе, используйте класс через его интерфейс, который является хорошей идеей так или иначе, правильно?
Пригодность для обслуживания более важна.
не упускают суть, что у обоих, поблочного тестирования и ООП есть та общая цель.
То, что Вы испытываете, - то, что тесты проявляют силы на дизайне. Это - на самом деле причина, почему TDD главным образом стратегия дизайна - запись, что тесты вызывают лучший отделенный дизайн, , если Вы обращаете внимание и знаете, как считать знаки.
Введение "объекты помощника" в классы является на самом деле хорошей вещью. Вы не должны думать о них как помощник объекты, все же. Они - регулярные объекты, надо надеяться, на другом уровне абстракции. Они - в основном Стратегии, которые настраивают, как детали высокоуровневых алгоритмов заполнены. (Я обычно ввожу их использующий конструктора и также предоставляю другому конструктору, который автоматически использует внедрение производственной среды по умолчанию, если существует тот.) Остерегаются, хотя - насмешка может также быть преувеличена, по моему опыту. Смотрят на http://martinfowler.com/articles/mocksArentStubs.html для некоторых интересных мыслей о теме.
Относительно закрытых методов, я не полностью понимаю то, что это имеет отношение к Вашей платформе насмешки - обычно, необходимо дразнить интерфейсы, которые только имеют открытые методы, так или иначе, которые являются частью государственного контракта.
Так или иначе, сложные закрытые методы являются запахом кода, по-моему - это - знак, что класс, вероятно, берет слишком много ответственности, нарушая Единственный Принцип Ответственности. Думайте о на том, какой класс это было бы на самом деле не быть нарушением инкапсуляции, чтобы обнародовать его. Перемещение метода к тому классу (возможно создающий его на пути), вероятно, собирается улучшить Ваш дизайн с точки зрения связи и сцепления.
я не знаком с rhinomocks, и на самом деле никогда не использовал или нуждался в инструменте насмешки, таким образом, я могу быть путем от основы здесь, но:
- должен быть никакой конфликт между принципами OO и TDD, потому что
- закрытые методы не должны быть протестированной единицей, только общедоступные
Можно также заняться расследованиями внедрение зависимости как способ воплотить некоторые классы помощника