Карма + Жасмин (угловое тестирование): где я должен определять фиктивные классы и тестовые переменные? - PullRequest
Новая
       13

Карма + Жасмин (угловое тестирование): где я должен определять фиктивные классы и тестовые переменные?

0 голосов
/ 13 декабря 2018

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

const listDefinition: any = {
    module: "module",
    service: "service",
    listname: "listname"
};

@Component(...)
class MockTreeExpanderComponent extends TreeExpanderComponent {...}

class MockListConfigurationsService extends ListConfigurationsService {...}

describe('ColumnsListConfigurationsComponent Test cases', () => {
    let fixture: ComponentFixture<ColumnsListConfigurationsComponent>;
    let component: ColumnsListConfigurationsComponent;
    beforeEach(() => {
        TestBed.configureTestingModule({
            declarations: [
                ComponentToTest,
                MockTreeExpanderComponent
            ],
            providers: [
                 { provide: TreeListConfigurationService, useClass: MockTreeListConfigurationService }
            ]
        });
        fixture = TestBed.createComponent(ComponentToTest);
        component = fixture.componentInstance;
        component.listDefinition = listDefinition;
        fixture.detectChanges();
    });
});

Как видите, у меня есть компонент Mock (MockListViewerGridComponent) и сервис (ListConfigurationsService), переменная конфигурации (listDefinition) иприбор и компонент, который я хочу протестировать.

Мой вопрос о performance и test memory management:

  1. Переменные, созданные внутри метода description, будут уничтожены, как тольковсе тесты внутри description заканчиваются?
  2. Должен ли я объявить все переменные и фиктивные классы / сервисы внутри description?
  3. Должен ли я создать фиксатор в beforeEach или beforeAll?Благодаря этому у меня будет улучшение производительности?

Спасибо!

Ответы [ 2 ]

0 голосов
/ 21 декабря 2018

У меня есть ответ для пункта # 3

. Позвольте мне поделиться своим собственным опытом с beforeAll.

. Мы использовали создание приспособления beforeEach в одном из наших приложений, котороепотребовалось почти 12 минут, чтобы собрать все приложение.Для each unit of work.

мы должны построить приложение

1st time client side

2nd time on review branch и

3rd time release branch

которые брали почти 30 min (вместе взятые), чтобы совершить unit of work.

Теперь умножив это время на бинго head count of resources, как команда, мы тратили много времени только на процесс сборки приложения.

В какой-то момент мы заменили beforeEach на beforeAll с помощью этой статьи , и все заработало.Мы смогли сократить время сборки примерно на 80%.

Краткие ответы по пунктам № 1 и № 2

1) Да

2) Лучше создать отдельный сервис-имитатор.Вы можете предоставить объект этого с помощью заглушки в вашем блоке before all и хранить все макеты в одной папке. 

providers: [
      { provide: XService, useClass: XServiceStub }
]
0 голосов
/ 19 декабря 2018

В своих проектах я всегда создаю фиктивные классы и тестовую переменную в отдельном файле.И после импорта их в мой spec-файл я объявляю их в блоке beforeEach:

  1. Основное преимущество заключается в том, что перед каждым блоком IT он сбрасывает свою предыдущую ссылку на значение.
  2. Неиспользуемые переменные удаляются из памяти, что приводит к повышению производительности.

Надеюсь, это поможет

...