Possibility to test directives against running backend (Directive Integration Test)

[andimarek]

Hi,

we would like to have the possibility do test a directive against a running backend.
Our usecase is the following:
A Directive receives JSON data from the backend which should be displayed to the user (e.g. a person).
We would like to test, that the person data binding works as expected: For example the backend sends a person.name and the directive should display the name.

An example pseudo code:

it("name should be shown", function(done){
  var element = createDirective("<person/>");
  notifyWhenNoOutstandingRequests(function(){
    expect(element.find(".name")).to.have.text("test name");
    done():
  }):
});

We don't want to use E2E/Protractor tests, because we are only interested in a single directive (and E2E tests are much slower than Unit-Tests), but we need to communicate with the server (real http requests) to verify the expectations of the directive regarding the data format are met.

Do you understand our intention and find it useful? If so we would happily provide a pull requests to make this kind of test possible. Currently we use a hacky patch of angular-mocks.

Regards,
Andi

[pkozlowski-opensource]

@andimarek I'm always wary about "unit tests" that use real HTTP server. Such tests are pain to setup (you need to have an HTTP server running somewhere), even more pain to maintain (you need to have an HTTP server running somewhere all the time), hard to offload on CI servers in the cloud. Not to mention that those are slow which means developers will naturally avoid running them. Personally I'm always avoid such setups like fire. Why can't you simply mock JSON responses from your server? This would have additional benefit of clearly stating the API between your directive and your backend.

At the moment I would not be too keen on making this use case easier - one should feel a bit of pain while doing things that shouldn't really been done.

I'm not saying that you don't have a real use-case - I just think you need to advocate it more to be actionable.

[andimarek]

@pkozlowski-opensource Thanks for your answer ... i will try to to explain our motivation behind this:

We see this kind of test as one element of our Test-Pyramide, between Protractor and Unit-Tests.

Protractor:

End-to-End use case tests, which simulate real user interaction. They are slow, they need the most complicated setup with Webdriver, backend etc, but they proof that the app as a whole is working as expected (for the tested use cases)

Directive Integration Tests:

This new kind of tests are much faster (and much more focused) than Protractor because they run directly in the browser (like Unit-Tests) but they need a backend, so yes, they are more complicated to setup than Unit-Tests. They are focused on one (or few) directive and not at the complete app. We use this kind of tests to verify the contract between the directive and the backend, so we want a real backend. We try to see our frontend and our backend as two loosely coupled components, which communicate only through HTTP-JSON. And so they can evolve, change and be redeployed at different times, but of course only when they still can "work together",i.e. the JSON from the backend is still valid for the directive (or service).

Perhaps the name for this kind of tests is not very good: Frontend integration tests or something similar might be better to make the intention clear.

Unit-Tests/Directive-Test:

Normal Tests with mocked dependencies. They proof that the service/directive/controller is working as expected, but not that the frontend and the backend fit, because the JSON from backend is mocked.

Best regards,
Andi

[gkalpak]

Now that #13124 has been merged into master, you might be able to do exactly what you want.
As discussed several times, we don't want to go to great extends enabling unit-tests to access the backend, since this against the nature of unit tests.

Argueably, there is still room for a "middle" testing layer - integration tests if you will (something between unit and e2e tests) - but at the moment, there is no built-in, dedicated testing module for that. Hopefully, #13124 will be enough though 😃