Я бы сказал, что это зависит немного больше от контекста.
Вы должны протестировать все, от чего вы зависите или что вы обещаете, в общедоступном API (также скрыть все, что не тестировалось).
Если этот метод является частью вашей библиотеки, убедитесь, что он выполняет все, что вы говорите в документации.Это устанавливает регистры на определенные значения и проверяет, что функция возвращает их правильно.
Если это внутреннее, и вы зависите только от его части, было бы хорошо проверить только эту часть и изменить документацию, чтобы сказать, что другиевещи не проверены и не должны использоваться (если не проверены должным образом).Скажем, вам нужно это только для получения указателя инструкций, чтобы вы могли вернуться назад к какой-то другой части кода, а затем только протестировать эту часть поведения.
Я бы не стал полностью пропускать тесты.В документации правильно указано, что есть какой-то компонент, специфичный для платформы.Было бы неплохо, если бы тест не прошел, если код требует чего-то определенного, чего не хватает в какой-то странной архитектуре.Он также может служить хорошим шаблоном для пользователей более экзотических архитектур для добавления своих собственных тестов, что делает код в целом более устойчивым.