Если поведение reader
вызывает onerror
при сбое readAsDataURL
, это должно сделать:
spyOn(newPracticeQuestionComponent.reader, 'readAsDataURL').and.callFake(() => {
newPracticeQuestionComponent.reader.onerror();
});
Поскольку это будет синхронный вызов, вы можете упростить утверждениев конце теста (после тройки А) вот так:
// Arrange
const newPracticeQuestionComponent = component;
spyOn(newPracticeQuestionComponent, 'handleReaderError');
spyOn(newPracticeQuestionComponent.reader, 'readAsDataURL').and.callFake(() => {
newPracticeQuestionComponent.reader.onerror();
});
let file1 = new File(["foo1"], "foo1.txt");
// Act
newPracticeQuestionComponent.handleFileSelect([file1]);
// Assert
expect(newPracticeQuestionComponent.handleReaderError).toHaveBeenCalledWith({ type: 'abort' });
Но я не рекомендую ожидать, что параметр передается в функцию, event.type
, потому что это спецификациядругого устройства , которое мы в настоящее время не тестируем.(мы тестируем newPracticeQuestionComponent
, а не поведение reader
, вызывающего ошибку с событием)
Насмешка над поведением reader
может быть не лучшим способом.Это зависит от того, что вы хотите проверить против устройства.
В случае, если мы хотим стать чрезвычайно независимыми, newPracticeQuestionComponent
не должен ничего знать о поведении reader
, даже об ошибке обратного вызова, единственное, что этот аппарат должен знать, это установить обратный вызов onerror
, вымогу просто утверждать, что вы правильно установили onerror
читателя.
// Arrange
const newPracticeQuestionComponent = component;
spyOn(newPracticeQuestionComponent.reader, 'readAsDataURL');
let file1 = new File(["foo1"], "foo1.txt");
// Act
newPracticeQuestionComponent.handleFileSelect([file1]);
// Assert
expect(newPracticeQuestionComponent.reader.onerror).toBe(newPracticeQuestionComponent.handleReaderError);
Я не мастер в тестировании, но, похоже, плюсы и минусы написание тестов, таких как приведенные выше и приведенные ниже примеры, по многим факторам.
Надеюсь, это поможет:)