What to Javascript-test in Lightning components and what not

Let’s be honest. As an Apex developer used to provide near-100% test coverage for Apex the same should be true for Lightning components. As we move more code from the server to the client more test need to be written in Javascript. Especially as JS is more error-prone than Apex.

When I listened to Keir Bowden’s Dreamforce 2016 talk about Lightning testing with Jasmine and read the docs for the current Lightning Testing Service (Pilot) (usable by everybody) many questions arise:

  1. Ignore Server actions: As (according to the docs) I am not supposed to invoke Apex actions from JS test, what should I then test?
  2. Test plumbing or only business logic: Lightning controllers have a lot of code even if they do near to nothing. How do I test all this error prone action calling, attribute reading and setting? And should I really do it with even more test code?
  3. What to mock?: How much should I use stubbing/mocking/spying to simulate server responses?
  4. Coverage: When can I be sure to have semantically covered my code well?
  5. UI testing: Should I use UI-testing (Selenium, Provar) as a third type for real end-to-end testing?
  6. Integration aspects: If not how can I be sure that JS indeed is triggering the right things in Apex?

and finally…

  1. and finally what happened to the Lightning Component Builder – Test UI promised for Summer ’17enter image description here

So the overarching question is:

What to test in Apex and what in Jasmine and how to ensure to cover everything well?

Answer

Some great questions here, and while I can’t answer all of them, let me (a) answer what I can, and (b) make it clear that we’re listening. 🙂

First, though, keep in mind that the Lightning Testing Service as it’s available today is a PILOT release. It’s incomplete, we know there are known and unknown unknowns, etc. Feedback is key to shaping the direction that the LTS takes going forward. So keep it up!

A couple of answers.

(1.) We think that if your tests depend on actual responses to full Apex requests, they’ll be “flappy”, that is, bounce between success and failure, because you’re testing too much in one test. Mock your Apex requests/responses, and test for the various possible responses. Test your Apex on the Apex side. (You have to do that anyway, for test coverage purposes, right?)

(4.) Coverage. Really good question. We don’t have an answer for you today, beyond what’s provided in e.g. Jasmine itself. It’s going to be a while before we give you Apex-style coverage reports. Safe harbor, etc.

(7.) Lightning Component Builder wasn’t a test UI, but a replacement for building components in the Developer Console. It was going to include new UI for tests, but the actual testing was going to be a separate feature. (Or so I’ve heard.)

In any event, the Lightning Component Builder as a specific tool is currently on hold. (If you’re on the partner community, a few details here: https://partners.salesforce.com/0D53A000038fWzJ) We’ve got a huge overall tooling initiative going in the form of Salesforce DX, and will have a lot more to say about all of that throughout the year, especially at TrailheaDX and Dreamforce.

TrailheaDX is just two weeks away. If you’re joining us there, please say hello to all the team members in attendance. We’re looking forward to meeting you, telling you more, and hearing what more we can do to make testing productive. (We know the list is long!)

Attribution
Source : Link , Question Author : Robert Sösemann , Answer Author : Alderete

Leave a Comment