How to mock or configure lightning:workspaceAPI in tests?

[KeithClarke]

I have a Lightning Component that uses the lightning:workspaceAPI component to detect that it is (or is not) running in the console view. I'm starting to look at setting up some LTS tests and am wondering what can be done to either mock or configure so that the lightning:workspaceAPI calls work?

The methods I'm using are:

• isConsoleNavigation
• getEnclosingTabId
• getFocusedTabInfo

and I want tests for both console view and non-console view.

(Nothing came back on this for this https://salesforce.stackexchange.com question).

[esalman-sfdc]

I suppose there are 2 approaches you can evaluate,

1- Try using mocking capabilities of the Test Framework. This is probably more practical as it doesn't require you change existing code. For example,

• Jasmine has some out of the box support via 'spyOn' which is also being used here by jasmine example.
• In case of mocha, LTS brings in sinonjs for mocking/spying which is being used here in a mocha example.

This thread also has some discussion about jasmine spies.

In your case, I am thinking that you would spy on find(), spyOn(component, "find").and.callFake(function(cId) {..}); to return some sort of proxy/mock.

2- Restructure/Reorganize the components for Dependency Injection where the leaf/UI components mostly act based on information provided to them by a wrapper/container, improving their testability.

[KeithClarke]

Hi Emad, Thanks for responding. Trying to establish good patterns here.

I think it would help if the https://github.com/forcedotcom/LightningTestingService page explained more about the execution context here i.e. what will work and what will not. In the debugger I see that the (not mocked) lightning:workspaceAPI component delegates to one:workspaceToolkit.js where $A.get("e.force:getEnclosingTabId") is undefined and so the call fails.

From my perspective, testing against a real lightning:workspaceAPI would be simpler and build more confidence that my components will work in the real environment.

Started looking at the spyOn option and its a pretty nasty peeking into the internal structure of the component under test and also requires the find of the lightning:workspaceAPI to be moved out of the init so the spy can be applied in the test in the create callback. Have you considered adding features to LTS such as tests being able to intercept <lightning:workspaceAPI aura:id="workspace"/> creates? (Not saying this specifically is a well though out idea, just that there is probably a set of common problems that people writing tests are going to run into and ready made solutions will stop people giving up.)

[esalman-sfdc]

'real environment' in some of these cases may imply that you need end-to-end UI tests (e.g. webdriver) instead of component tests. For example if your component changes behavior based on an internal/contextual check for the container/environment, from a component test you won't have much control over what that check returns. You could break up your code into smaller parts and leave the logic around contextual checks in a 'container/stateful component' and have most of your custom logic in the presentation/functional component.

Pros/cons of spies/mocking-frameworks vs make code more testable are fairly standard topics (concepts are language agnostic) when it comes to unit/component testing. For example just google for 'writing testable code'.

Current scope of LTS is to enable the use of standard testing tools and building blocks for Lightning. I have however seen a consumer build a mock registry of sort on top of jasmine's spies functionality which they always initialized with a handful of mocks before a test run.

[KeithClarke]

OK thanks for taking the time to comment. We've some AngularJS Karma (and Protractor) tests that I remember being fairly painless to get working. But maybe I've forgotten the bad parts...