Prenons l'exemple suivant:
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();
});
});
Comme vous pouvez le constater, j’ai un composant Mock (MockListViewerGridComponent
) et un service (ListConfigurationsService
), une variable de configuration (listDefinition
) et l’appareil et le composant que je souhaite tester.
Ma question concerne performance
et test memory management
:
beforeEach
ou beforeAll
? En faisant cela, j'aurai une amélioration de la performance?Je vous remercie!
J'ai une réponse pour le point # 3
permettez-moi de partager ma propre expérience avec beforeAll
.
Nous utilisions la création de luminaires beforeEach
dans l'une de nos applications qui prenait presque 12 minutes pour créer une application complète. Pour each unit of work
.
nous devons construire l'application
1st time client side
2nd time on review branch
et
3rd time release branch
qui prenaient presque 30 min
(combiné) pour valider unit of work
.
Maintenant plusieurs fois avec le head count of resources
, bingo en tant qu'équipe, nous perdions beaucoup de temps uniquement dans le processus de construction de l'application.
à un moment donné, nous avons remplacé beforeEach
par beforeAll
avec l'aide de cet article , et cela a fonctionné. Nous avons pu réduire le temps de construction d'environ 80%.
Réponses courtes aux points 1 et 2
1) oui
2) Il est préférable de créer un service de simulation séparé . Vous pouvez en fournir l'objet à l'aide d'un tronçon à l'intérieur de votre bloc avant tout, et conserver toutes les copies dans le même dossier.
providers: [
{ provide: XService, useClass: XServiceStub }
]
Dans mes projets, je crée toujours des classes fictives et des variables de test dans un fichier séparé. Et après les avoir importées dans mon fichier de spécification, je les déclare dans le bloc beforeEach
:
IT
, il réinitialise sa référence précédente de valeur.J'espère que ça aide