-
10 |
- {!accountName} 12 |
https://<myServer>/c/jasmineTests.app (Jasmine)
137 | https://<myServer>/c/mochaTests.app (Mocha)
138 |
139 | You should see a screen that looks something like the following.
140 |
141 | 
142 |
143 | This page tells you that the package is correctly installed and LTS is working in your org.
144 |
145 | ## Next Steps
146 |
147 | When you have the LTS package installed and working in your org, you’re ready to begin exploring the test code, and even writing your own tests. Here are some next steps for you to take.
148 |
149 | ### Explore the Example Test Suites
150 |
151 | To dive into the test suites and start learning how to write tests for your Aura components, explore the tests and the components being tested side-by-side. You’ll want to open the test suite file in one window, and in another window (perhaps in your IDE) open the simple components being tested.
152 |
153 | Both the components and the test suites included in the unmanaged package are also available in a repository on GitHub:
154 |
155 | [https://github.com/forcedotcom/LightningTestingService](https://github.com/forcedotcom/LightningTestingService)
156 |
157 | #### Components for Testing
158 |
159 | All of the testable components are named beginning with “eg” (from the abbreviation “e.g.”, meaning _for example_). The components provided in the package can be accessed as you would any Aura component.
160 |
161 | - In the Developer Console
162 | - In the Force.com IDE, in the `/aura/` directory
163 | - By converting your org’s metadata into a format that you can work with locally, using Salesforce CLI
164 |
165 | You can also explore the components directly from the repo. They’re available in the [lightning-component-tests/main/default/aura](https://github.com/forcedotcom/LightningTestingService/tree/master/lightning-component-tests/main/default/aura) directory.
166 |
167 | There are more than a dozen different components, designed to be used in illustrative tests. Each of the components has a description of its behavior in its `.auradoc` documentation file.
168 |
169 | #### Test Suites
170 |
171 | The example tests are included in the form of static resources. You can also review them directly in the repo, in the [lightning-component-tests/test/default/staticresources](https://github.com/forcedotcom/LightningTestingService/tree/master/lightning-component-tests/test/default/staticresources) directory.
172 |
173 | There are four test suites included in the LTS package, three for Jasmine and one for Mocha:
174 |
175 | - `jasmineHelloWorldTests.resource` — A very simple Jasmine example including one passing and one failing test.
176 | - `jasmineExampleTests.resource` — The main Jasmine example test suite.
177 | - `jasmineLightningDataServiceTests.resource` — Some Jasmine examples specific to testing Lightning Data Service-based components.
178 | - `mochaExampleTests.resource` — The Mocha example test suite, which provides examples parallel to the main Jasmine test suite.
179 |
180 | The remainder of the static resources are infrastructure used by the LTS. They’re _briefly_ described in [Use Another JavaScript Test Framework](#use-another-javascript-test-framework).
181 |
182 | The `jasmineExampleTests.resource` and `mochaExampleTests.resource` files are each a single JavaScript file containing a complete test suite. It’s a single file for convenience in delivery and exploration. Your own test suites can include many such files. The test suites are copiously commented. The code and comments serve as the official documentation for how to write tests.
183 |
184 | ### Write Your Own Tests
185 |
186 | A separate document, [Testing Lightning Components with the Lightning Testing Service](https://github.com/forcedotcom/LightningTestingService/blob/master/developer-workflow.md), describes the flow, or lifecycle, of using the LTS to automate your testing. Once you’ve explored the example tests, use this document to dive into writing a test suite for your own custom components.
187 |
188 | ### Use Another JavaScript Test Framework
189 |
190 | The Lightning Testing Service provides a way to use standard JavaScript test frameworks with your Aura components. We’ve provided the example test suites implemented in [Jasmine](https://jasmine.github.io/) and [Mocha](http://mochajs.org/). These are well-regarded test frameworks, and if you haven’t chosen one already, we recommend you start with one of them.
191 |
192 | If you’d prefer to use another test framework, either because you’ve already selected one, or because you find something more to your taste, you can use it with the LTS instead.
193 |
194 | All of the packaged pieces of the LTS are included in the project repository, in the [lightning-component-tests/test/default](https://github.com/forcedotcom/LightningTestingService/tree/master/lightning-component-tests/test/default) directory. The pieces you’ll need to modify or replace are the following items, drawn from the Jasmine wrapper.
195 |
196 | - `aura/jasmineTests` — The front end of the LTS, this simple app includes the test runner component, and a list of test suites to feed it.
197 | - `aura/lts_jasmineRunner` — The test runner component for Jasmine. It includes references to the required Jasmine library, which it loads along with the test spec resources, and then fires the test runner.
198 | - `lts_jasmine.resource` — The Jasmine library, unmodified.
199 | - `lts_jasmineboot.resource` — A JavaScript IIFE that launches Jasmine in the LTS context.
200 | - `lts_testutil.resource` — A collection of utilities for use within your test specs, and by the test framework wrappers. They provide Lightning component-specific functions that make it easier to test your custom components from a test context.
201 |
202 | The Mocha version of the framework wrapper provides similar files. You might find the similarities and differences instructive in creating your own adapter for other frameworks.
203 |
204 | If you’re already experienced with setting up another test framework, adapting the Jasmine examples should take you a day or so, but not longer. We’d be thrilled to hear more about your adventures with other JavaScript test frameworks!
205 |
--------------------------------------------------------------------------------
/_config.yml:
--------------------------------------------------------------------------------
1 | theme: jekyll-theme-slate
--------------------------------------------------------------------------------
/assets/server.key.enc:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/forcedotcom/LightningTestingService/fde6caccd834a29d3b9b671df3c10c5d53fe7033/assets/server.key.enc
--------------------------------------------------------------------------------
/config/lts-config.json:
--------------------------------------------------------------------------------
1 | {
2 | "webdriverio": {
3 | "desiredCapabilities": {
4 | "browserName": "chrome",
5 | "chromeOptions": {
6 | "args": ["--headless"]
7 | }
8 | }
9 | }
10 | }
11 |
--------------------------------------------------------------------------------
/config/project-scratch-def.json:
--------------------------------------------------------------------------------
1 | {
2 | "orgName": "My Company",
3 | "country": "US",
4 | "adminEmail": "myEmail@myCompany.com",
5 | "edition": "Developer",
6 | "settings": {
7 | "lightningExperienceSettings": {
8 | "enableS1DesktopEnabled": true
9 | }
10 | },
11 | "hasSampleData": true
12 | }
13 |
--------------------------------------------------------------------------------
/developer-workflow.md:
--------------------------------------------------------------------------------
1 | # Testing Lightning Components with the Lightning Testing Service
2 |
3 | The Lightning Testing Service, or LTS, is a set of tools and services that let you create test suites for your Lightning components using standard JavaScript test frameworks like Jasmine.
4 |
5 | If you haven’t already installed the LTS, start with [the project introduction](./README.md) instead of this document.
6 |
7 | ## Developer Workflows
8 |
9 | This document provides background on how the LTS works, both by itself and when used with Salesforce DX. We’ll also describe a number of common tasks you might perform while doing development work. You can combine these tasks with each other and with your own developer processes. The workflows enabled by the LTS can significantly improve your overall development lifecycle.
10 |
11 | ## LTS Basics and Some Theory of Operation
12 |
13 | The LTS consists of two major components:
14 |
15 | * The LTS unmanaged package
16 | * The LTS command for the Salesforce CLI
17 |
18 | The unmanaged package includes LTS infrastructure, including a test runner app, and some example tests. Once the package is installed in your org, you can run the example tests by going to the following URL:
19 | yourInstance/c/jasmineTests.app
20 |
21 | When you run tests manually in a browser, you’re using only the pieces of LTS provided in the package.
22 |
23 | 
24 |
25 | For more sophisticated development processes, use the LTS commands included with the salesforcedx CLI plugin. The Salesforce CLI allows you to integrate the LTS into your automated testing, continuous integration, and other source-based development processes.
26 |
27 | The command line tool automates running your test suites. It opens the same URL you can open manually, and uses WebDriver to observe the test suite as it runs. Then it parses and packages the results for use in command line-based development processes.
28 |
29 | ## Common Tasks and Workflows
30 |
31 | Many of the tasks presented here are common to all Salesforce DX workflows. They’re presented here because they’re commonly used when you’re writing tests, too. For more details, be sure to read the Salesforce DX documentation.
32 |
33 | ### Prerequisites
34 |
35 | Make sure you’ve installed the LTS unmanaged package and updated to the latest salesforcedx CLI plugin for Salesforce DX, as described in [the project introduction](./README.md).
36 |
37 | ### Create a Scratch Org
38 |
39 | It’s usually best to perform automated testing in a clean org, created with consistent settings.
40 |
41 | 1. Customize your scratch org default settings using a [scratch org configuration file](config/project-scratch-def.json). You can use this to specify a company name, email address, and so on.
42 |
43 | 2. Log in to your Dev Hub.
44 |
45 | ```bash
46 | sfdx force:auth:web:login -d
47 | ```
48 |
49 | 3. Create a scratch org and set it as the default for your project workspace.
50 |
51 | ```bash
52 | sfdx force:org:create -s -f config/project-scratch-def.json -a scratch1
53 | ```
54 |
55 | ### Install the Lightning Testing Service Package
56 |
57 | You can quickly install the LTS unmanaged package into an org with the following command:
58 |
59 | ```bash
60 | sfdx force:lightning:test:install -t jasmine
61 | ```
62 |
63 | > Note that this command installs the jasmine version of LTS unmanaged package into your org, enabling you to create wrapper test applications and author jasmine tests.
64 |
65 | ### Push Metadata to a Scratch Org
66 |
67 | Your tests are written as JavaScript files saved in archive static resources. When you update your tests locally, you need to push the new static resource to the org you’re using for testing.
68 |
69 | 1. Push local metadata to your scratch org.
70 |
71 | ```bash
72 | sfdx force:source:push
73 | ```
74 |
75 | 2. Log in to your scratch org in a web browser. Use the ```-p``` (```--path```) parameter to open your test suite’s app directly for manual review.
76 |
77 | ```bash
78 | sfdx force:org:open -p /c/jasmineTests.app
79 | ```
80 |
81 | 3. Update your code, or your tests, and go to step 1. Repeat until you achieve perfection, or at least 100% passing tests.
82 |
83 | ### [Alternative] Push Metadata to a Developer Edition (DE) Org
84 |
85 | Salesforce DX is designed to work with a Dev Hub and scratch orgs. If you have a normal DE org you’d like to work with, the commands are slightly different.
86 |
87 | ```bash
88 | sfdx force:auth:web:login -s # connect to your DE org
89 | sfdx force:source:push -f # push local source to the DE org
90 | ```
91 |
92 | The ```-f``` flag forces all local changes to be pushed to the DE org. Be careful with this flag! It will overwrite changes you’ve made in the org without warning you.
93 |
94 | ### Run Tests
95 |
96 | For a manual test run, visit the appropriate test app, for example, yourInstance/c/jasmineTests.app.
97 |
98 | 
99 |
100 | For automated test runs, use the Salesforce CLI.
101 |
102 | ```bash
103 | sfdx force:lightning:test:run -a jasmineTests.app
104 | ```
105 |
106 | See the command line help for other useful details.
107 |
108 | ```bash
109 | sfdx force:lightning:test:run --help
110 | ```
111 |
112 | ### Debugging Tests
113 |
114 | When a test fails, is it a bug in your software implementation, or a bug in the test itself? Use your standard browser-based JavaScript debugging tools to investigate the behavior of both your production code and your test code.
115 |
116 | 
117 |
--------------------------------------------------------------------------------
/doc-resources/lts_browser_debugging_example.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/forcedotcom/LightningTestingService/fde6caccd834a29d3b9b671df3c10c5d53fe7033/doc-resources/lts_browser_debugging_example.png
--------------------------------------------------------------------------------
/doc-resources/lts_package_app_success.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/forcedotcom/LightningTestingService/fde6caccd834a29d3b9b671df3c10c5d53fe7033/doc-resources/lts_package_app_success.png
--------------------------------------------------------------------------------
/doc-resources/lts_sfdx_test_run_output.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/forcedotcom/LightningTestingService/fde6caccd834a29d3b9b671df3c10c5d53fe7033/doc-resources/lts_sfdx_test_run_output.png
--------------------------------------------------------------------------------
/doc-resources/lts_test_suite_page_success.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/forcedotcom/LightningTestingService/fde6caccd834a29d3b9b671df3c10c5d53fe7033/doc-resources/lts_test_suite_page_success.png
--------------------------------------------------------------------------------
/doc-resources/metadata-visualization-and-runtime-flowchart.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/forcedotcom/LightningTestingService/fde6caccd834a29d3b9b671df3c10c5d53fe7033/doc-resources/metadata-visualization-and-runtime-flowchart.png
--------------------------------------------------------------------------------
/lightning-component-tests/main/default/aura/egApplicationEvent/egApplicationEvent.auradoc:
--------------------------------------------------------------------------------
1 | An application-level event for use in example components.
4 |An example component with attributes of various types.
4 |String: {!v.stringAtr}
18 |Integer: {!v.integerAtr}
19 |Boolean: {!v.booleanAtr}
20 |Date: {!v.dateAtr}
21 |Sobject: {!v.sobjectAtr.sObjectType}
22 |Account: {!v.accountAtr.sObjectType},{!v.accountAtr.Name}
23 |Object: {!v.objectAtrStringified}
24 |Aura.Component[]: {!v.AuraComponentAtr}
25 |An example component that updates the user interface based on processing 4 | done by a client-side action.
5 |A component-level event for use in example components.
4 |An example component that exposes a method on component's public API. 4 | The method updates a component attribute when called.
5 |An example component that conditionally renders text to its body (and 4 | the DOM). Visibility can be toggled via a button that references a 5 | client-side action.
6 |An example component that handles events: one application-level event and 4 | one component-level event.
5 |An example component for a test of facets. It passes text content into a facet of the component it wraps (c:egAttributeTypes).
An example component that outputs a custom label using the $Label global 4 | value provider.
5 |A complex component with extensive opportunities for testing.
4 | 5 |This is a presentation component that contains view logic without a direct dependency on Lighting Data Service (LDS). This pattern explores ways to decouple presentation logic from server/integration logic.
6 | 7 |Some of the decoupling illustrated is necessary because LDS can currently only be used inside Lightning Experience. (This is a documented limitation of the LDS beta.)
8 | Account Name:
Account Industry:
Account Type:
An example component that's very simple. 4 | It renders static text to the DOM.
5 |An example component that calls a server-side action, and which also 4 | exposes the action callback as a method that can be called directly.
5 |