Don’t delete .spec file in Angular!

Day after day, I have been improving my code, and I have read some important books (Clean Code; The Clean Coder; Domain-Driven-Design…)

What is a simple project? According to Uncle bob :

  1. Do all the tests
  2. No code duplication
  3. Express the programmer’s purpose
  4. Minimize the number of classes and methods

Check this out! He put:

DO ALL THE TESTS in the first.

I had some difficulty to undertanding this affirmation because I never seen a good use case with TDD (Test-driven development).

But in my last task I could undertand. Basically, I needed create a “simple notification” with a lot of rules.

The problem

  • A started programming and after solving something I broke something else.
  • It was very exhausting for me, because I need to follow a big “script”
  • I wrote a good code, but I had a lot of difficults to review this script.

My worry

  • If someone get need to change the code?
  • Will he follow the script?
  • Because the script is in my mind and probably after some days I will forget.
  • How to ensure peace of mind for the future?
  • So I decided to write unit test in Angular!

The Big Mistake

  • I know Angular and I have already worked on big projects with this framework.
  • I created this course in Angular too.
  • However, I had never created a unit test with Angular 😨
  • When using the command: ng generate component we get this result:

  • But I always deleted the file .spec because I never implemented anything.
  • So, to me, it made sense.

Difficults to implements unit test

  • After I started implementing the unit test I had some challenges just to compile the component.
  • “Ok… It’s my first time doing that, I thought”.
  • And in my first time attempt, I tried to implement unit test in a complex component 🤡

Components must be independent

  • When working with Web Components, we need to follow some recommendations.
  • Each component must be independent.
  • However, sometimes we forget this, and the application still work the same.
  • For example: The parent component import module “x”, and the child component needs module “x”, but the programmer forgets to add it.
  • The sofware is still able to run, but this component has a problem.

What problem?

  • If I try to use the child component in another parent, and it doesn’t import module “x”, we will have problems to use the component.
  • This case emphasizes the importance of independence.

My head exploded

  • Because the .spec in Angular solve this situation very simply.
  • How? I create this simple test:
describe('DialogViewNotificationComponent', () => {
  let component: DialogViewNotificationComponent;
  let fixture: ComponentFixture<DialogViewNotificationComponent>;

  beforeEach(async () => {
    await TestBed.configureTestingModule({      
      imports: [DialogViewNotificationModule],
      providers: [
          provide: MatDialogRef,
          useValue: getDialogRefMock()
          provide: MAT_DIALOG_DATA,
          useValue: {
            message: getMessageUnread(),
            idOpen: 290,
            byEvtMessage: true,
            viewMessageEnum: ViewMessageEnum.MESSAGE_NO_READ
    fixture = TestBed.createComponent(DialogViewNotificationComponent);
    component = fixture.componentInstance;    
  • But I received this error:

  • The reason was that I didn’t add HttpClientModule and others modules either.
  • In other words, my component was not independent.
  • Look at the differences:



  • Now I got success!

  • And I will start to implements the units tests.
  • Without much effort, I can garantee the independence of my component.
  • It’s so fanny because I tried to control this situation, and I failed many times.
  • I wrote this post: (🇧🇷) What happens when importing unnecessary modules in Angular?
  • Because I saw a lot of developers using unnecessary modules in some component, and that is wrong.
  • But create a component  that is not independent also is and the unit test helped me!
  • Now, all of my components will have .spec file!


Thanks, Uncle Bob! Thank you for reading! See you next time 🙂


Leave a Reply