TDD - высокоуровневая функция имеет слишком много насмешек. Я должен даже потрудиться тестировать его?

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

Я бы порекомендовал работать с этой функцией:

xmlToList(books)

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

После того, как вы решили, что делать с вопросом нескольких авторов, то это довольно прямо вперед, чтобы превратить вашу книгу список в кадр данных с функцией ldply () в plyr (или просто использовать plapply и преобразовать возвращаемое значение в data.frame с помощью do.call («rbind»...).

Вот полный пример (исключая автора):

library(XML)
books <-  "w3schools.com/xsl/books.xml"
library(plyr)
ldply(xmlToList(books), function(x) { data.frame(x[!names(x)=="author"]) } )

   .id        title.text title..attrs year price   .attrs
 1 book  Everyday Italian           en 2005 30.00  COOKING
 2 book      Harry Potter           en 2005 29.99 CHILDREN
 3 book XQuery Kick Start           en 2003 49.99      WEB
 4 book      Learning XML           en 2003 39.95      WEB

Вот как он выглядит с включенным автором. Вы должны использовать ldply в этом случае, так как список «зазубренный»... приложение не может обработать это должным образом. [В противном случае вы можете использовать lapply с rbind.fill (также любезно предоставлено Хэдли), но зачем беспокоиться, когда plyr автоматически делает это для вас?]:

ldply(xmlToList(books), data.frame)

   .id        title.text title..attrs              author year price   .attrs
1 book  Everyday Italian           en Giada De Laurentiis 2005 30.00  COOKING
2 book      Harry Potter           en        J K. Rowling 2005 29.99 CHILDREN
3 book XQuery Kick Start           en      James McGovern 2003 49.99      WEB
4 book      Learning XML           en         Erik T. Ray 2003 39.95      WEB
     author.1   author.2   author.3               author.4
1        <NA>       <NA>       <NA>                   <NA>
2        <NA>       <NA>       <NA>                   <NA>
3 Per Bothner Kurt Cagle James Linn Vaidyanathan Nagarajan
4        <NA>       <NA>       <NA>                   <NA>

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

Ваши тесты слишком сложны.

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

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

Я не думаю, что вы делаете что-то неправильно. Локальная ветвь не зависит от существования удаленной ветви, поэтому удаленная ветвь должна быть удалена, в то время как локальная ветвь (с тем же именем и, по-видимому, той же историей) должна продолжать существовать. Это «централизованный» подход, который вы описываете, если что, который будет считаться неортодоксальным в Git.

Edit: Tangential, вас могут заинтересовать опции --track и -no-track для git-branch, а также переменная конфигурации branch.autosetupmerge .

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

Целочисленные типы:

short            -> signed short
signed short
unsigned short
int              -> signed int
signed int
unsigned int
signed           -> signed int
unsigned         -> unsigned int
long             -> signed long
signed long
unsigned long

Будьте внимательны к символу:

char  (is signed or unsigned depending on the implmentation)
signed char
unsigned char

ядро Linux может быть записано в C. Оно все еще компилируется для машинного кода. И именно этот машинный код выполняется во время загрузки

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

Наконец: Я не думаю, что людям это не так нравится, если им нужно перезагрузить свой компьютер, чтобы запустить ваше программное обеспечение. Так что я бы пошел писать для ОС... это облегчает жизнь для вас и пользователя.

Я предполагаю, что каждый тест для Run () устанавливает ожидания для каждого метода, который они вызывают для насмешек, даже если этот тест не фокусируется на проверке каждого такого вызова метода. Я настоятельно рекомендую вам Google «издевательства не заглушки» и читать статью Фаулера.

Кроме того, 50 строки кода довольно сложны. Сколько кодепатов через метод? 20+? Вы можете извлечь выгоду из более высокого уровня абстракции. Мне нужно увидеть код, чтобы судить более точно.

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

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

Таким образом, вы можете быть уверены, что вход и выход - это то, что желательно.

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

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

О том, будет ли тестировать такую ​​функцию: вы сказали в комментарии

«Тесты прочитаны так же, как фактический функция, и так как я использую издевательства, это только утверждение функций называется и отправляются парам (я могу проверить Это глазок 50 линий Функция) "

imho eyeballing Функция недостаточно, вы не слышали:« Я не могу поверить, что я пропустил это! »... У вас есть честное количество сценариев, которые могут ошибаться в этом методе Покрытие этой логики является хорошей идеей.

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

На тестах слишком долго / трудно узнать, что находится в том, что там: не тестируйте односмысленные сценарии с каждым единственным утверждением, что это связано с Это. Разбивайте его, тестируйте такие, как он должен регистрировать X сообщений, когда Y получится (1 тест), он должен сохранить до БД, когда y получится (еще один отдельный тест), он должен отправить запрос на третью сторону, когда Z возникает ( Еще один тест) и т. Д.

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

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

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

Итак, я должен даже беспокоить это Функция высокого уровня?

Да. Если есть разные кодовые пути, вы должны быть.

А что я делаю, делаю это? Или я полностью не буду с использованием издевательства / заглушки Объекты здесь?

как j.b. Указал (приятно видеть вас в Agileindia2010!), Статья Fowler рекомендуется прочитать. Как валовая упрощение: используйте заглушки, когда вам все равно, если вы не заботитесь о значениях, возвращаемых сотрудниками. Если вы возвращающие значения от Collaborator.call_method () изменяют поведение (или вам нужны нетривиальные проверки args, вычисления для возвратных значений), вам нужны издевалки.

Предлагаемые рефакторины:

1. Попробуйте переместить создание и впрыск издеваний в общее метод настройки. Большинство структур тестирования единиц поддерживают это; Будут вызвать перед каждым тестом
2. Ваши вызовы logmessage - это маяки - вызов еще раз, чтобы намеренные раскрывать методы. например Submitbarrequest (). Это сократит ваш код производства.

3. Попробуйте переместить каждое ожидаемое .blah1 (..). Это сократит ваш тестовый код и делает его очень читаемым и легче изменить. например Заменить все экземпляры Отказ

   ждет .once.on (Mockdao) _ .Method ("beginjob") _ .With (новый объект () {permatedby, clientid, Rundate, "Отправлено для BARING"}) _ .Will ([return] .value (0));

с

engivebeginjobondao_andreturnuzero (); // Вы можете назвать его лучше

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