Как Вы делаете TDD в нетривиальном приложении? [закрытый]

Несколько лет спустя просто добавить еще одно простое базовое R-решение, которое по какой-то причине отсутствует здесь xtabs

xtabs(Frequency ~ Category, df)
# Category
# First Second  Third 
#    30      5     34 

Или, если хотите data.frame назад

as.data.frame(xtabs(Frequency ~ Category, df))
#   Category Freq
# 1    First   30
# 2   Second    5
# 3    Third   34
15
задан Rob Prouse 16 November 2008 в 22:48
поделиться

8 ответов

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

я нашел атомарные объектные статьи о Предъявителе Сначала очень полезными. Я все еще запускаю путем предположения пользовательских действий, которые я хочу реализовать (если у Вас есть варианты использования, это - отличный способ запуститься), и использование MVP или модели MVC-выхода, которую я запускаю с записи теста для предъявителя первого экрана. Путем копирования представления, пока предъявитель не работает, я могу начать действительно быстро этот путь. http://www.atomicobject.com/pages/Presenter+First вот больше информации о прокладывании себе путь.

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

4
ответ дан 1 December 2019 в 04:34
поделиться

Я запускаю с thinkig требований.

foreach UseCase

  1. анализирует UseCase
  2. , думают о будущих классах
  3. , записывают тестовые сценарии
  4. тесты записи
  5. тестирование и классы с реализацией (иногда добавляющий новые тесты, если я пропустил sth в точке 4).

Вот именно. Это довольно просто, но я думаю, что это является трудоемким. Мне нравится он, хотя и я придерживаюсь его. :)

, Если у меня есть больше времени, я пытаюсь смоделировать некоторые последовательные схемы в Архитекторе Предприятия.

3
ответ дан 1 December 2019 в 04:34
поделиться

Это легче, чем Вы думаете на самом деле. Вы просто используете TDD на каждом отдельном классе. Каждый открытый метод, который Вы имеете в классе, должен быть протестирован на все возможные результаты. Так "подтверждение концепции" примеры TDD, которые Вы видите, могут также использоваться в относительно крупном приложении, которое имеет много сотен классов.

Другая стратегия TDD, которую Вы могли использовать, моделирует сами тестовые прогоны приложения путем инкапсуляции поведения главного приложения. Например, я записал платформу (в C++, но это должно относиться к любому языку OO), который представляет приложение. Существуют абстрактные классы для инициализации, основного runloop и закрытия. Так мое основное () метод выглядит примерно так:

int main(int argc, char *argv[]) {
  int result = 0;

  myApp &mw = getApp(); // Singleton method to return main app instance
  if(mw.initialize(argc, argv) == kErrorNone) {
    result = mw.run();
  }

  mw.shutdown();
  return(result);
}

преимущество выполнения этого является двукратным. В первую очередь, вся функциональность главного приложения может быть скомпилирована в статическую библиотеку, которая затем связана и против набора тестов и против этого main.cpp тупикового файла. Во-вторых, это означает, что я могу моделировать все "выполнения" главного приложения путем создания массивов для argc & argv [], и затем моделирование, что произошло бы в основном (). Мы используем этот процесс для тестирования большой реальной функциональности, чтобы удостовериться, что приложение генерирует точно, что это, как предполагается, делает, учитывая определенный реальный корпус входных данных и параметров командной строки.

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

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

5
ответ дан 1 December 2019 в 04:34
поделиться

Я соглашаюсь, что особенно трудно загрузить процесс.

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

Actor1 говорит Actor2, что мир в беде, Actor2 возвращает пакет, Actor1 распаковывает пакет, и т.д.

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

кроме того, я уверен последняя вещь, которую Вы хотите сделать, читается другая книга, но у парней по MockObjects.com есть книга в ранних стадиях разработки, в настоящее время называемых Растущее Объектно-ориентированное программное обеспечение, Ведомое Тестами . Главы, которые в настоящее время являются для обзора, могут дать Вам некоторое дальнейшее понимание в том, как запустить TDD и продолжить его повсюду.

1
ответ дан 1 December 2019 в 04:34
поделиться

Проблема состоит в том, что Вы смотрите на свою клавиатуру, задающуюся вопросом, что тестирует Вас, должен записать.

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

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

1
ответ дан 1 December 2019 в 04:34
поделиться

Я не думаю, что необходимо действительно начать с TDD. Серьезно, где Ваши спецификации? Вы договорились об общем/грубом общем замысле для своей системы уже, это может подходить для Вашего приложения? Я знаю, что TDD и гибкий препятствует Большому Дизайну Заранее, но это не означает, что Вы не должны делать Дизайна Заранее сначала перед TDDing Ваш путь посредством реализации того дизайна.

0
ответ дан 1 December 2019 в 04:34
поделиться

Иногда Вы не знаете, как сделать TDD, потому что Ваш код не является "тестом, дружественным" (легко тестируемый).

Благодаря некоторым хорошим методам Ваши классы могут стать легче протестировать в изоляции, достигнуть истинного поблочного тестирования.

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

Вот одни из его недавних переговоров , которым я повторно управляю.

Он настаивает на том, что необходимо разделить бизнес-логику от кода создания объекта (т.е. постараться не смешивать логику с 'новым' оператором), при помощи шаблона Внедрения зависимости. Он также объясняет, как Закон Demeter важен для тестируемого кода. Он главным образом фокусируется на коде Java (и Guice), но его принципы должны относиться к любому языку действительно.

0
ответ дан 1 December 2019 в 04:34
поделиться

Самое легкое должно запуститься с класса, который не имеет никаких зависимостей, класс, который используется другими классами, но не использует другой класс. Затем необходимо ли взять тест, спросив себя, "как я знал бы, реализован ли этот класс (этот метод) правильно?".

Затем Вы могли записать первый тест для опроса объекта, когда он не инициализируется, он мог возвратить ПУСТОЙ УКАЗАТЕЛЬ или выдать исключение. Затем можно инициализировать (возможно, только частично) объект и протестировать тест, он возвращает что-то ценное. Затем можно добавить, что тест с другим значением инициализации - должен вести себя тот же путь. В то время я обычно тестирую состояние ошибки - такое как попытка инициализировать объект с недопустимым значением.

то, Когда Вы сделаны с методом, переходит к другому методу того же класса, пока Вы не сделаны с целым классом.

Затем Вы могли выбрать другой класс - или другой независимый класс или класс, которые используют первый класс, который Вы реализовали.

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

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

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

<час>

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

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

0
ответ дан 1 December 2019 в 04:34
поделиться
Другие вопросы по тегам:

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