Вопросы Теги

Начало TDD - проблемы? Решения? Рекомендации? [закрытый]

После игры с ним в течение очень долгого времени, это то, что я придумал: 

    jQuery.fn.scrollTo = function (elem) {
        var b = $(elem);
        this.scrollTop(b.position().top + b.height() - this.height());
    };

, и я называю это следующим образом: 

$("#basketListGridHolder").scrollTo('tr[data-uid="' + basketID + '"]');
43
задан Community 23 May 2017 в 12:34
поделиться

11 ответов

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

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

Взятие вышеупомянутый абзац в памяти, давайте посмотрим на Ваши вопросы:

  1. , Если я использую набор в своей системе под тестом, тогда я установлю ожидание удостовериться, что код назвали, чтобы вставить объект и затем утверждать количество набора. Я не обязательно тестирую Добавить метод в своем внутреннем списке. Я просто удостоверяюсь, что это назвали, когда метод, который добавляет объект, называют. Я делаю это путем добавления платформы насмешки в соединение с моей средой тестирования.
  2. строки Тестирования, поскольку вывод может быть утомительным. Вы не можете объяснить каждый результат. Можно только протестировать то, что Вы ожидаете на основе функциональности системы под тестом. Необходимо всегда ломать тесты к самому маленькому элементу, который это тестирует. Что означает, что у Вас будет много тестов, но тесты, которые являются маленькими и быстрыми и только тестируют то, что они должны, ничто иное.
  3. существует много сред тестирования с открытым исходным кодом для выбора из. Я не собираюсь спорить, который является лучшим. Просто найдите тот, который Вы любите и начинаете использовать его.
  4. Все, что можно сделать, установить тесты для составления то, что Вы хотите произойти. Если сценарий подходит, который представляет ошибку в Вашей функциональности, по крайней мере, у Вас есть тест вокруг функциональности, чтобы добавить что сценарий в тест и затем изменить Вашу функциональность до тестовых передач. Один способ найти, где мы, возможно, пропустили тест, состоит в том, чтобы использовать покрытие кода .

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

  • Moq: Открытый исходный код
  • RhinoMocks: Открытый исходный код
  • TypeMock: Коммерческий продукт
  • NSubstitute: Открытый исходный код

Один способ помочь в использовании TDD, помимо чтения о процессе, должен наблюдать, что люди делают это. Я рекомендую в наблюдении экранных бросков мировым судьей Boodhoo на DNRTV. Проверьте их:

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

я думаю, что сделал бы несправедливость сообществу, если бы я не обновил это путем добавления нового ряда Kent Beck на [1 117] Разработка через тестирование на Прагматически настроенном Программисте .

50
ответ дан Dale Ragan 26 November 2019 в 23:01
поделиться

На основе моего собственного опыта:

  1. Только тестируют Ваш собственный код, не код базовой платформы. Таким образом, при использовании универсального списка тогда нет никакой потребности протестировать, Добавляют, Удаляют и т.д.

  2. существует № 2. Посмотрите там! Обезьяны!!!

  3. NUnit является способом пойти.

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

6
ответ дан Matt Hamilton 26 November 2019 в 23:01
поделиться

Мое взятие на этом следует:

  • +1 для не код среды тестирования, но Вы, возможно, все еще должны протестировать классы, полученные из классов платформы.
  • , Если некоторый класс/метод является громоздким для тестирования его, может быть верный признак, что что-то неправильно с дизайном. Я пытаюсь следовать "за 1 классом - 1 ответственностью, 1 методом - 1 действие" принцип. Тем путем Вы будете в состоянии к методам испытательного комплекса, намного легче путем выполнения этого в меньших частях.
  • +1 для xUnit. Для Java можно также рассмотреть TestNG.
  • TDD не является единственным событием, это - процесс. Не пытайтесь предположить все с начала, но удостовериться, что каждая ошибка, найденная в коде, на самом деле покрыта тестом, однажды обнаруженным.
2
ответ дан Dima Malenko 26 November 2019 в 23:01
поделиться

Я думаю самая важная вещь с (и на самом деле один из больших результатов, несколько рекурсивным способом), TDD является успешным управлением зависимостями. Необходимо удостовериться, что модули тестируются в изоляции без тщательно продуманной необходимой установки. Например, если Вы тестируете компонент, который в конечном счете посылает электронное письмо, сделайте почтового отправителя зависимостью так, чтобы можно было дразнить его в тестах. Это приводит к второй точке - насмешки являются Вашими друзьями. Будьте ознакомлены с насмешкой платформ и стиля тестов, которые они продвигают (поведенческий, в противоположность классическому базирующемуся состоянию), и проектные решения, которые они поощряют ( "Говорят, не спрашивайте" принцип).

2
ответ дан On Freund 26 November 2019 в 23:01
поделиться

Я нашел, что принципы, проиллюстрированные в Три Учетных карточки для легкого Запоминания Сущности TDD, являются хорошим руководством.

Так или иначе, для ответа на вопросы

  1. Вы не должны тестировать что-то, что Вы "знаете", собирается работать, если Вы не записали его. Вы не записали дженериков, Microsoft сделала;)
  2. , Если необходимо сделать так много для теста, возможно, объект/метод делает слишком много также.
  3. Загрузка TestDriven.NET для непосредственного запуска поблочного тестирования на Visual Studio, (кроме того, если это - выпуск Экспресса)
  4. Просто тестирует корректная вещь, которая произойдет . Вы не делаете потребность для тестирования всего, что может пойти не так, как надо: необходимо ожидать тестов для сбоя для этого.

Серьезно, просто сделайте это, чувак.:)

2
ответ дан Jon Limjap 26 November 2019 в 23:01
поделиться

Я не эксперт в TDD, каким-либо образом, но здесь являюсь моим представлением:

  • , Если это абсолютно тривиально (методы get/методы set и т.д.) не тестируют его, если Вы не уверены в коде по некоторым причинам.
  • , Если это - довольно простой, но нетривиальный метод, протестируйте его. Тест, вероятно, легко записать так или иначе.
  • , Когда дело доходит до что ожидать не происходить, я сказал бы, что, если определенной потенциальной проблемой является ответственность класса, Вы тестируете, необходимо протестировать это, это обрабатывает его правильно. Если это не ответственность текущего класса, не тестируйте его.

xUnit среды тестирования часто свободны использовать, поэтому если Вы-.Net парень, проверяете NUnit, и если Java является Вашей вещью выезд JUnit.

0
ответ дан Erik Öjebo 26 November 2019 в 23:01
поделиться

Вышеупомянутый совет хорош, и если Вы хотите список свободных платформ, необходимо посмотреть не дальше, чем xUnit Список Платформ на Википедию. Надежда это помогает:)

0
ответ дан Eric Scrivner 26 November 2019 в 23:01
поделиться

По-моему (Ваш пробег может варьироваться):

1-, Если Вы не записали, это не тестирует его. Если Вы записали его, и у Вас нет теста для него, это не существует.

3-, Как все сказали, xUnit's, свободный и большой.

2 & 4-Решений точно, что протестировать, являются одной из тех вещей, о которых можно дебатировать с собой навсегда. Я пытаюсь провести эту линию с помощью принципов дизайна контракта. Выезд 'Разработка объектно-ориентированного программного обеспечения" или "Прагматически настроенный Программист" для получения дополнительной информации о нем.

0
ответ дан Chris B-C 26 November 2019 в 23:01
поделиться

Сохраните тесты короткими, "атомарными". Протестируйте самое маленькое предположение в каждом тесте. Сделайте каждый TestMethod независимым для интеграционных тестов, я даже создаю новую базу данных для каждого метода. Если необходимо создать некоторые данные для каждого тестового использования метод "Init". Используйте насмешки для изоляции класса тестирование от, он - зависимости.

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

0
ответ дан Chris Porter 26 November 2019 в 23:01
поделиться

За прошлый год я стал более убежденным в преимуществах TDD. Вещи, которые я изучил по пути: 1) внедрение зависимости является Вашим другом. Я не говорю об инверсии контейнеров управления и платформ для сборки сменной архитектуры, просто передающие зависимости в конструктора объекта под тестом. Это выплачивает назад огромные дивиденды в тестируемости Вашего кода. 2) я отправился со страстью / фанатизм преобразования и захватил платформу насмешки и приступил к использованию насмешек для всего, что я мог. Это привело к хрупким тестам, которые потребовали большого количества болезненного набора и упадут, как только я запустил любой рефакторинг. Используйте корректный вид теста дважды. Фальшивки, где просто необходимо удостоить чести интерфейс, тупики подавать данные назад к объекту под тестом, насмешка только там, где Вы заботитесь о взаимодействии. 3) Тест должен быть маленьким. Стремитесь к одному утверждению или взаимодействию, протестированному в каждом тесте. Я пытаюсь сделать это, и главным образом я там. Это об устойчивости тестового кода и также о сумме сложности в тесте, когда необходимо пересмотреть его позже.

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

0
ответ дан Hamish Smith 26 November 2019 в 23:01
поделиться

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

" TDD †“Начинающий с Разработкой через тестирование " - я имею некоторую большую обратную связь до сих пор и действительно больше ценил бы, что парни необходимо предложить.

я надеюсь, что это помогает!:)

0
ответ дан Rob Cooper 26 November 2019 в 23:01
поделиться
Другие вопросы по тегам:

Похожие вопросы: