2017-02-17 36 views
0

Как часть добавления пользовательских интерфейсов XCode к нашему потоку CI, я решил реализовать повторное выполнение неудачных тестов перед сбоем сборки из-за общей ненадежности тестовой среды.Как идентифицировать неудавшиеся тестовые примеры при сканировании Fastlane для повторной передачи?

Я могу избежать сбоя сборки сразу, используя блок rescue, это не проблема, и расположение файлов отчетов (JUnit и HTML) исправлено, поэтому их можно открыть, например, File.readlines.

Формат файла отчета юнита - это каскад testuites -> testuite -> testcase -> сообщение об ошибке, если применимо, а затем назад достаточно далеко для следующего элемента. Кажется довольно стандартным.

Однако в этот момент я немного застрял (и это может быть не правильный путь, есть ли канонический лучший способ сделать это в первую очередь?). В bash я бы использовал grep -B, чтобы вытащить строку до сообщения об ошибке, которое было бы именем неудачного тестового примера, а затем захватить соответствующий фрагмент текста с помощью awk. Легкая команда двухтрубной оболочки, которую я могу затем вернуть обратно в scan/xcodebuild с помощью параметра -only-testing.

Есть ли способ сделать это с аналогичной легкостью в Ruby или junit-плагине, который позволит мне читать только имена отдельных неудачных тестовых случаев?

ответ

1

В случае, если кто работает в этот вопрос когда-нибудь в будущем:

def parse_ui_test_report 
doc = File.open("#{REPORT_LOCATION}/report.junit") { |f| Nokogiri::XML(f) } 
node_tree = doc.css('testcase') 
test_identifiers_to_rerun = node_tree.map do |node| 
    # Test case nodes in the JUNIT XML doc don't have children unless they failed 
    if node.first_element_child 
    node.values.join('/').gsub('.','/') 
    end 
end.select {|str| !str.nil? && !str.empty? } 

return test_identifiers_to_rerun 
end 

 Смежные вопросы

  • Нет связанных вопросов^_^