Как выполнить модульное тестирование «не автономных функций»?

Вы сделали ценное открытие:

Самый простой способ написания кода не обязательно является самым надежным способом написания кода.

Эта досадная проблема усугубляется тем, как большинство людей используют классы: неявная ссылка this позволяет очень легко сделать слишком много в одном методе, не говоря уже об одном классе. И это привело вас ко второму ценному открытию:

Одна из самых ценных вещей в изолированных модульных тестах заключается в том, что они дают вам отзывы о вашем проекте.

Здесь трудность выделения теста говорит вам о том, что вы соединили отдельные проблемы таким образом, что их трудно разделить. У вас есть метод с семью (7!!) различными точками выхода, и теперь вы застряли, потому что это много насмешек, чтобы попытаться вызвать соответствующую логику, чтобы убедиться, что вы нажмете все из них .

Рассмотрите следующий вариант:

const FAIL = {}; // could also use Symbol() here, any unique ref
const BAD_NAMES = ['fake whatever'];
async function apiCall1() {
  const resp = await fetch(someURL);
  return resp.json();
}

function validate1(data) {
  return data?.name === undefined || BAD_NAMES.includes(data?.name) 
    ? FAIL 
    : data.name;
}

// You can imagine what validation and fetching look like for
// the second API call

function processData(data) {
  switch(data.currency){
    case 'EURO':
      return 'Euro';
    case 'Pound':
      return 'Pound';
    default: 
      return 'Dollar';
  }
}

async function doTheThing() { // use a better name IRL
  try {
    const first = await apiCall1();
    const data = validate1(first);
    if (data === FAIL) throw new Error('whatever');
    
    const second = await apiCall2(data.whatever);
    const data2 = validate2(second);
    if (data2 === FAIL) throw new Error('something else');

    // process data we now know is good.
    return processData(data);
  } catch (err) {
    console.error(err);
    return 'Failure';
  }
}

class Screen1 extends React.Component {
  async proceedApiCheck () {
    const nextScreen = await doTheThing();
    this.navigateToScreen(nextScreen);
  }
}
      

1. Здесь мы возвращаем триггер экрана сбоя в только в одном месте. Все функции имеют четкие выходы.
2. Есть удобная функция, которая распаковывает запрос (или скрывает детали xhr, если вы так поступаете).
3. Вся валидация и бизнес-логика поддаются независимому тестированию. Он также находится в одном месте, а не разбросан по разным местам в длительном режиме.
4. Вся логика находится в простых функциях, которые возвращают значения, не требуется имитаций, кроме как для fetch.
5. Единственная вещь, которую делает continueApiCheck, — это получение значения из логической функции и переход к нужному экрану, а также простая имитация для теста.

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

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