файлы типа "build" модульного теста
Этот код должен работать:
let
Source = Excel.CurrentWorkbook(){[Name="Data"]}[Content],
group = Table.Group(Source, {"ProductID"}, {"temp", each _}),
list = Table.AddColumn(group, "list", each List.Skip(List.Accumulate([temp][ReceiptQty], {0}, (a, b) => a & {List.Last(a) + b}))),
table = Table.AddColumn(list, "table", each Table.FromColumns(Table.ToColumns([temp])&{[list]}, Table.ColumnNames(Source)&{"RunningQty"})),
final = Table.SelectRows(Table.Combine(table[table]), each [OnhandQty] >= [RunningQty])
in
final
3 ответа
Вот подход, который мы использовали при создании большой базы кода (многие миллионы строк кода), охватывающей больше, чем десяток платформ.
- Изменения в Makefile проверяются командой сборки. Эти люди знают об ошибках, которые люди обычно допускают в нашей среде сборки, и именно они чувствуют на себе всю тяжесть этого, когда сборка прерывается, поэтому они заинтересованы в поиске проблем.
- Сведите к минимуму то, что должно быть в Makefile. , поэтому вероятность ошибки меньше. У нас есть слой поверх make, который генерирует Makefile. Разработчик просто должен указать в файле более высокого уровня с помощью тегов, что, например, данная цель является общей библиотекой или модульным тестом. Обычно цель определяется в одной строке, что затем приводит к нескольким настройкам / целям в сгенерированном Makefile. Аналогичные вещи можно сделать с помощью таких инструментов сборки, как scons , которые позволяют абстрагироваться от таких вещей, как специфические для платформы детали, делая цели очень простыми.
- Модульные тесты нашего инструмента сборки. Инструмент написан на Perl, поэтому мы используем Perl Test :: More среду модульного тестирования, чтобы убедиться, что инструмент генерирует правильный Makefile для нашего файла более высокого уровня. Если бы вместо этого мы использовали что-то вроде scons, я бы использовал их среду тестирования .
- Модульные тесты наших ночных скриптов сборки / тестирования. У нас есть набор сценариев, которые запускают ночные сборки на каждой платформе, запускают инструменты статического анализа, запускают модульные тесты, запускают функциональные тесты и сообщают обо всех результатах в центральную базу данных. Мы тестируем различные сценарии по отдельности, в основном используя среду модульного тестирования shunit2 для sh / bash / ksh / и т. Д.
- Сквозные тесты нашего процесса сборки / тестирования. Я работаю над сквозным тестом, который работает с крошечным деревом исходных текстов, а не с нашим производственным кодом, поскольку на сборку последнего могут уйти часы. Эти тесты в основном нацелены на проверку того, что наши цели сборки по-прежнему работают, и отправляют результаты в нашу центральную базу данных даже после, например, обновления нашего инструмента покрытия кода или внесения изменений в наши сценарии сборки.
Создайте файл сборки для компиляции известной версии вашего программного обеспечения (или более простого фрагмента кода, аналогичного с точки зрения сборки) и сравните результат, полученный с помощью ваших новых инструментов сборки, с ожидаемым результатом. (построен с использованием проверенной версии инструментов сборки).
В моих проектах файлы сборки меняются не очень часто. Более того, я могу повторно использовать файлы сборки из более ранних проектов, изменяя только некоторые переменные (которые я переместил в легко узнаваемый раздел). Вот почему мне не нужно проводить модульное тестирование файлов сборки. В других проектах все может быть иначе.