Локализация для мобильной кроссплатформенности с использованием xamarin и проблема только с iOS

Посмотрите отчет JUnit. JUnit уже организован пакетом. Каждый пакет имеет (или может иметь) классы TestSuite, каждый из которых, в свою очередь, запускает несколько TestCases. Каждая TestCase может иметь несколько тестовых методов формы public void test*(), каждая из которых фактически станет экземпляром класса TestCase, к которому они принадлежат. Каждый тестовый метод (экземпляр TestCase) имеет имя и критерии прохождения / отказа.

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

В прошлом разработчики тестов в моем положении организовали классы TestCase в пакеты, соответствующие части (-ям) тестируемого продукта, создал класс TestCase для каждого теста и сделал каждый тестовый метод отдельным «шагом» в тесте с его собственными критериями прохождения / отказа в выводе JUnit. Каждый TestCase является автономным «тестом», но отдельные методы или «этапы» теста в TestCase должны выполняться в определенном порядке.

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

Например:

Class testStateChanges extends TestCase

public void testCreateObjectPlacesTheObjectInStateA()
public void testTransitionToStateBAndValidateStateB()
public void testTransitionToStateCAndValidateStateC()
public void testTryToDeleteObjectinStateCAndValidateObjectStillExists()
public void testTransitionToStateAAndValidateStateA()
public void testDeleteObjectInStateAAndObjectDoesNotExist()
public void cleanupIfAnythingWentWrong()

Каждый метод тестирования утверждает и сообщает о своих собственных критериях прохождения / отказа. Свертывание этого в «один большой тестовый метод» для упорядочения теряет степень детализации критерия прохождения / отказа каждого «шага» в сводном отчете JUnit. ... и это расстраивает моих менеджеров. В настоящее время они требуют другой альтернативы.

Может ли кто-нибудь объяснить, как JUnit с упорядоченным методом тестирования скремблирования будет поддерживать отдельные критерии прохождения / отказа каждого последовательного тестового шага, как показано выше и требуется моим руководством?

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