Хорошо, у меня есть кое-что, что работает и готово, чтобы вы могли взглянуть на него, по сути, подход состоит в том, чтобы отделить тестирование презентации от бизнес-логики. c Я протестировал контракты между компонентами / поставщиками, чтобы убедиться, что используются правильные методы вызывается изнутри.
Это повторяется во всех соответствующих компонентах, это тестирует только logi c за кнопками.
В e2e я тестировал, чтобы обеспечить модальное отображение, и кнопки присутствуют, по общему признанию, вы также должны убедиться, что модальное окно исчезло, а кнопки также исчезли и больше не были включены, но я уверен, что вы не ищете здесь полный пример.
Это разделение задач, позволяющее держать logi c подальше от вашего пользовательского интерфейса. Как я уже упоминал в своем комментарии выше, я лично предпочел бы использовать модульное тестирование только для моего logi c и тестирование e2e для компонентов пользовательского интерфейса (гарантируя, что если вы нажмете кнопку, оно будет извлечено из службы или чего-то еще. ваше намерение может быть).
В общем, хватит разговоров, еще кода. Я отправлю несколько примеров для всех, кто окажется в положении, аналогичном OP. Ссылка на Github внизу.
Модульное тестирование будет выглядеть примерно так:
it('.reject() should call activeModal with false', async () => {
spyOn(activeModal, 'close').and.returnValue(null);
expect(component.decline()).toBeUndefined();
expect(activeModal.close).toHaveBeenCalledTimes(1);
expect(activeModal.close).toHaveBeenCalledWith(false);
});
И:
it('should return the correct result of a Modal (object is correct, calls internal modal)', async () => {
const mock = {
componentInstance: {
title: 'Are you sure?',
message: 'Are you actually sure though?',
btnOkText: 'OK',
btnCancelText: 'Cancel',
},
result: true,
};
spyOn(modal, 'open').and.returnValue(mock as any);
const result = await service.confirm(
mock.componentInstance.title,
mock.componentInstance.message
);
expect(result).toBe(mock.result);
expect(modal.open).toHaveBeenCalledTimes(1);
expect(modal.open).toHaveBeenCalledWith(ModalComponent, { size: 'sm' });
});
Тогда как мое тестирование e2e будет выглядеть примерно так:
it('should have an Open button on the home page, the button should open a modal with an OK option (returning TRUE)', async () => {
page.navigateTo();
const button = await page.getButton();
expect(button.getText()).toBe('Open');
await button.click();
const modal = await page.getConfirmationModal();
expect(await modal.isEnabled()).toBeTruthy();
const acceptBtn = await page.getAcceptButton();
expect(await acceptBtn.isDisplayed()).toBeTruthy();
expect(await acceptBtn.isEnabled()).toBeTruthy();
expect(await acceptBtn.getText()).toBe('OK');
await acceptBtn.click();
});
Это не самое элегантное тестирование (если бы я потратил больше времени, он бы проверил больше областей, но я уверен, что вы сможете получить этот бит).
Я также скажу , это не совсем правильный , технология в целом не означает правильный и неправильный , однако я не совсем уверен, как анализировать DOM события будут работать в модульном тестировании.
Хотя тестирование logi c вполне возможно (своего рода цель (IMO)).
https://github.com/Isolated-/angular-dialog-example-stack-overflow
Надеюсь, это каким-то образом помогло развеять ваше разочарование, если у меня возникла неправильная идея, дайте мне знать, и я исправлю это!