Angular-cli: Injecting Services in Component causes component.spec errors

[RicardoVaranda]

Please provide us with the following information:

1. OS? Windows 7, 8 or 10. Linux (which distribution). Mac OSX (Yosemite? El Capitan?)
   Linux Ubuntu 16.04
2. Versions. Please run ng --version. If there's nothing outputted, please
   run in a Terminal:
   node --version
   And paste the result here.

angular-cli: 1.0.0-beta.6
node: 6.2.1
os: linux x64

1. Repro steps. Was this an app that wasn't created using the CLI? What change did you
   do on your code? etc.
   Added a service to the constructor of a new component like:

constructor(private _userService:UserService, private _vmService: VMService) {
}

spec looks like:

describe('Component: WMKS', () => {
  it('should create an instance', () => {
    let component = new WMKSComponent();
    expect(component).toBeTruthy();
  });
});

1. The log given by the failure. Normally this include a stack trace and some
   more information.

/home/ricardo/WebstormProjects/TrialUI/tmp/broccoli_type_script_compiler-input_base_path-gLdunWag.tmp/0/src/app/components/vm-nav/vm-nav.component.spec.ts (17, 21): Supplied parameters do not match any signature of call target.

1. Mention any other details that might be useful.

This seems right to me I'm only wondering how I can reference my services without creating a new instance of them to get rid of this error message.

---

Thanks! We'll be in touch soon.

[RicardoVaranda]

Changing this line:

let component = new WMKSComponent();

to this:

let component = WMKSComponent;

Seems to have fixed the issue for now, probably not the correct way to handle it so I'll wait patiently for further instructions :+1:

[filipesilva]

You're right in saying it breaks, and the intention is that it does breaks. There was a fair bit of discussion regarding the specs recently, and we opted to make them dead simple. Let me explain why though.

We had a lot of feedback that the previous spec files were big and intimidating. It was hard for someone not accustomed to unit tests to get started on them since they contained a lot of A2 specific functionality. In addition, the testing guide at https://angular.io/docs/ts/latest/guide/testing.html is still incomplete so it would be hard for people to get a lot of information about A2 specific testing methodologies.

So we opted to take out pretty much everything that was A2 specific - mostly TestComponentBuilder and friends. Now the test simple creates a instance from a class and tests it.

Now, after you make that component anything remotely useful, the test will break. Mostly because any component that does anything uses services, and using services via DI changes the component signature, and thus compilation fails with Supplied parameters do not match any signature of call target.. This fail also happened with TestComponentBuilder for any non-hello-world project.

This means that you'll have to import and supply services to the component without DI:

new WMKSComponent(new UserService(), new VMService());

Alternatively, you can also dig deeper into A2 specific testing to use TestComponentBuilder.

But you will soon run into another snag: it is likely that the services you need will have DI dependencies themselves... and so forth. And then you will think this is bullshit, you can't possibly import everything and the kitchen sink into this test.

At that time we expect users to realize that fundamental issue with unit testing, that DI dependencies are hard. And to start mocking everything - which is a good practice in unit tests.

So this is the narrative we had for those changes in the unit tests, and we hope it helps introduce new users to unit tests in a somewhat organic fashion.

[yeiniel]

But angular-cli was created to make developing with angular2 easier. Now the developer need to read about testing angular components because the test created by the tool are incomplete. I think that instead of removing good testing infrastructure may be it can be properly documented to guide the developer into the right way of using the code.

[jeffaxial]

I have been struggling with this and have been tearing my app apart just to figure out why it couldn't run a simple test.

Maybe there should be some sort of messaging to indicate this test's purpose? Either in the unit testing documentation on the README or something in the test error messaging or even just a comment in the ng generated test file that lets a developer know that it will break their tests once they implement any services and to remove it.

This might be common sense to some? But I'm fairly new to unit testing, and this put a big hurdle into getting up and running with it. A little messaging would go far.

Thanks!

[filipesilva]

@yeiniel you will always need to read up on testing features of Angular 2. No amount of boilerplate code on a test will prevent that.

@jeffaxial I didn't add any documentation because unfortunately, there is no complete official documentation yet. There is partial documentation on www.angular.io and we're working hard to get the testing chapter up to date.

[yeiniel]

@filipesilva i understand your point. We will always need to read the documentation. But the current state of things is: you can use the cli to create artifacts without reading any documentation. But the code it generate for tests is in practice unusable unless you read it completely. If the cli is made to make things easier then it should make testing easier. Why i need to read the entire testing documentation just to create a working boilerplate for tests? Given the state of things test boilerplate need to be simple but not too simple to make it unusable in practice.

[filipesilva]

@yeiniel I don't see how it's unusable. You have a class you're testing, and if you change the class you have to change the test. If you add a parameter to the constructor, you have to add it to the test as well. That is how unit testing works.

The provided boilerplate is the one that doesn't require you to read anything else actually, since it minimized the A2 specific code. You still need to have a grasp of Karma and Jasmine, but it's stated that testing uses that.

[yeiniel]

@filipesilva the problem is that adding a new parameter to the component constructor do not translate into modifying the test suite to handle the new parameter. It translate into adding boilerplate code to the test suite because Angular use DI and the test suite assume not using it. You are creating a test for an Angular component, not any kind of component. Angular will load the component using DI no matter if the component has constructor parameters or not. Then why not include the DI boilerplate in the test suite?

[filipesilva]

When you do let component = new WMKSComponent(arg1, arg2); there is no DI happening, it's just a class constructor being called. To add DI, you need A2 specific test code.

[bkarv]

Thanks filipesilva the solution works for a normal service. However in Angular 2.0.0, I still get the same 'Supplied parameters do not match any signature of call target' when trying inject a Router. My code is as follows:

Component
constructor(private componentComm: ComponentComm, private router: Router) { }

Spec

describe('Component: NavPanelMenu', () => {
  it('should create an instance', () => {
    let component = new NavPanelMenuComponent(new ComponentComm(), new Router());
    expect(component).toBeTruthy();
  });
});

Visual Studio Code is highlighting the new Router() in red. What would be the correct syntax?

[deebloo]

@bkarv that is because Router also needs arguments. I recommend reading the Angular2 testing documentation To understand setting up TestBed to handle dependency injection.
https://angular.io/docs/ts/latest/guide/testing.html

[filipesilva]

Closing as an old issue that's already been answered.

[angular-automatic-lock-bot[bot]]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{_This action has been performed automatically by a bot._}