0

I have this kind of tests in most of the services I test and I'm not sure if I should reuse them by extending some base test class or by doing something else.

 it('should call HttpClient.get method', () => {
     // Arrange

     // Act
     callServiceWithDefaultArguments();

     // Assert
     expect(httpClient.get).toHaveBeenCalled();
 });

or like this test where I test if it throws an exception with null argument

it('with null id should throw an exception', () => {
      // Arrange
      const exceptionMessage = new RegExp(ExceptionConstants.NULL_OR_UNDEFINED);
      id = null;

      // Act

      // Assert
      expect(() => callServiceWithDefaultArguments()).toThrowError(exceptionMessage);
 });
manfrom
  • 91
  • 7

1 Answers1

0

I wouldn't implement DRY for unit testing or testing code like how it is in production code because if a unit test fails I want to only look at the beforeAll, beforeEach, afterEach, afterAll, it blocks and understand what is failing now rather than jumping from class to class to understand what is failing.

That being said, try using beforeAll, beforeEach, afterEach, afterAll to keep the test code DRY.

A very good exchange is here on why you should favor DAMP (Descriptive and meaningful phrases) over DRY for test code.

AliF50
  • 16,947
  • 1
  • 21
  • 37