Как я могу проверить абстрактный фрагмент Android с помощью инструментального теста?

Question

У меня есть задача проверить абстрактный фрагмент https://github.com/Mobile-Connect/android_sdk_v3/blob/develop/Application/src/main/java/com/gsma/mobileconnect/r2/android/demo/fragments/BaseAuthFragment.java с помощью инструментальных тестов. И я совершенно не понимаю, как это сделать правильно.

Я прочитал некоторый учебник, но это единственный подвал ... так что теперь у меня есть несколько мыслей о:

1. 1) Я должен использовать ActivityTestRule , потому что мне нужно занятие для добавить мой фрагмент к этому.
2. 2) мой класс (фрагмент) абстрактный, поэтому общаться с этим я наследую свой тестовый класс от него, а затем я создайте экземпляр моего тестового класса для работы с методами фрагмента.

Итак, теперь у меня есть такая структура:

@RunWith(AndroidJUnit4.class)
public class BaseAuthFragment_ExampleTest extends BaseAuthFragment{

    @Override
    public void onComplete(DiscoveryResponse discoveryResponse) {}

    @Rule
    public ActivityTestRule<MainActivity> mActivityRule = new ActivityTestRule<>(MainActivity.class);
    private MainActivity mainActivity = null;
    BaseAuthFragment fragment = null;

    @Before
    public void setUp() {
        //MockitoAnnotations.initMocks(this);
        mainActivity = mActivityRule.getActivity();
    }

    @After
    public void setDown() {
        mainActivity = null;
        fragment = null;
    }

    @Test
    public void useAppContext() throws Exception {
        assertNotNull(mainActivity);
        FragmentManager fragmentManager = mainActivity.getSupportFragmentManager();
        FragmentTransaction fragmentTransaction = fragmentManager.beginTransaction();
        fragment = new BaseAuthFragment_ExampleTest();
        MobileConnectAndroidView as = BaseAuthFragment.mobileConnectAndroidView;
        fragmentTransaction.add(fragment, null);
        fragmentTransaction.commit();

        getActivity().runOnUiThread(new Runnable() {
            @Override
            public void run() {
                getActivity().getSupportFragmentManager().executePendingTransactions();
            }
        });

        getInstrumentation().waitForIdleSync();

        fragment.connectMobileDemo();
        MobileConnectAndroidView as2 = BaseAuthFragment.mobileConnectAndroidView;
        assertThat(as, is(as2));
    }
}

Я хочу объяснить свои мысли на примере первого метода ( connectMobileWithoutDiscovery ):

1. во-первых, установлено mobileConnectConfig , но оно защищено. Так что есть 2 варианта, как по мне:
   • просто пропустите тест этого
   • попытаться получить разницу в этом объекте до и после вызова метода, используя отражение. (может быть, я даже могу попытаться высмеять возвращенные значения такие методы, как withClientSecret и withCacheResponsesWithSessionId и проверьте, что он был вызван с правильными параметрами).
2. тогда мы можем увидеть вызов метода setupMobileConnect , но это тоже личное, и я не знаю, стоит ли мне использовать внешние библиотеки как powermockito, чтобы проверить, что он был вызван или я должен просто проверить статическое поле вызова метода до и после mobileConnectAndroidView , установленный в этом методе.

Итак, я просто хочу знать, думаю, в правильном направлении или нет.

Answer 1

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

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

ТакжеСоздавая фрагмент, предназначенный для тестирования (но это не ваш тест), вы можете свободно расширять видимость методов ограниченной видимости (protected).Тем не менее, если вы будете придерживаться практики помещения ваших тестов в тот же пакет, что и тестируемый класс (возможно, в другую исходную папку), вы все равно сможете получить доступ к этим методам без изменения видимости: protected менее защищен, чемуровень видимости частного пакета по умолчанию.