Начальное состояние магазина избыточной нагрузки в Detox Testing

Question

проблема

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

---

Что я пробовал

Я сделал несколько начальных состояний, которые загружают определенный экран, чтобы я мог проверить его напрямую, и для каждого запуска теста на детоксикацию я загружаю разные mocha.opts, чтобы выбрать эту часть тестовых случаев, и использовал'act-native-config', чтобы я мог загрузить другое состояние в каждом запуске, например, для загрузки экрана я буду делать следующее:

1. Создайте initialState для магазина приставок, в котором есть все детали экрана, который я сейчас тестирую.
2. Создайте mocha.opts для запуска только этого теста, указав в нем флаг -f.
3. Создайте файл.env.test.screenX, который сообщит магазину, какое начальное состояние загружать в соответствии с выбранным ENVFILE.
4. Создайте различные конфигурации для каждого экрана в режиме detox, чтобы он мог загружать правильные настройки через moto detox CLI.
5. каждый раз, когда я запускаю команду ENVFILE=env.test.screenXact-native run-ios, чтобы проект создавался с использованием этой конфигурации, я мог затем запустить тест detox -c .

---

Вопрос

Мой метод настолько сложен и требует много настроек и накладных расходов для запуска тестирования для каждого экрана, поэтому мне было интересно, если у кого-то была такая же проблема, и как я мог бы ее решить? В общем, как я могу иметь дело с реагировать родной поток в детоксикации?

Answer 1

Я думаю, что детокс не может взаимодействовать с нативной нитью во время выполнения и изменять состояние, поэтому я подумал о небольшом хаке, использующем технику насмешки, как упоминал Leo Natan, он может быть полезен в вашем случае

Вы можете смоделировать свой файл App.js с помощью экрана (App.e2e.js), в котором есть несколько кнопок с известными идентификаторами testID, каждая из которых отправляет все действия, необходимые для сохранения определенного состояния для сохранения. Вы можете запустить каждый набор тестов, нажав одну из кнопки в beforeEach метод, то вы можете начать свой обычный тестовый поток после этого

например:

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

App.e2e.js имеет 2 кнопки:

• один для аутентификации, который отправляет действие как onAuthenticationSuccess(user, authToken)
• еще один для навигации к этому экрану this.navigation.navigate("screenName")

test.js

describe("Screen work as intended", () => {
  beforeEach(async () => {
    await device.reloadReactNative();
    await element(by.id("authButtonID")).tap();
    await element(by.id("navigateButtonID")).tap();
  });

  it("should do something", async () => {
    //user is loaded in store
    //current screen is the screen you want to test
  });
});

Answer 2

Если вы используете Expo и ее релиз-каналы для определения среды, вот что вы можете сделать:

1. Создать метод resetStorage как предложено здесь: Как сбросить состояние магазина Redux? (который вы могли бы уже реализовать в logout)
2. В App.js импорт resetStorage метод
3. В App.js добавьте: import { Constants } from 'expo'

4. Затем добавьте кнопку с testID="resetStorageBtn" на ваш render метод, который вы можете использовать в целях тестирования и который не будет виден в рабочей версии канала. Так render может выглядеть примерно так:

   return (
     <Root>
       {Constants.manifest.releaseChannel !== 'production' &&
           (<View>
             <Button onPress={() => resetStorage()} testID="resetStorageBtn">
               <Text>Reset storage</Text>
             </Button>
           </View>
         )}
       <View>
         <AppNavigator />
       </View>
     </Root>
   );