Testing
Copy link“Test as you build” philosophy
As mentioned in the introduction, we recommend starting with an initial version and improving your product step-by-step by adding additional functionality and features to your product. An integral part of this development process is to be able to test your product with either real or mocked devices to see that everything is working as expected, and fix some inevitable and unavoidable bugs. Our recommendation during this process is to launch and test your application with real end users as soon as possible, and avoid having long-running test pilots before the product is launched. Our experience shows that organizations which dare to launch their product in the market earlier end up with shorter development times and a better overall product. This also allows for your product to be quickly and incrementally improved based on user feedback
A great way to launch early versions of your product, or a new feature of your product, is through a soft launch. A soft launch means giving a select group of end users access to the new product or feature, before launching to the general public. In this way, bugs and errors are only exposed to a select group of users and can be fixed quickly before launching to a wider audience.
Copy linkTesting in Enode environments
As mentioned in Planning your integration Enode offer two environments, Sandbox and Production. Sandbox allows for testing with mocked devices and data, and production environments allow linking of real devices. These environments offer different testing opportunities and benefits.
Copy linkTesting in Sandbox
Copy linkSandbox API
Using our API in the Sandbox environment (https://enode-api.sandbox.enode.io
) is a great way to understand how the API behaves and provides a stable environment for you to write and test your integration. This can include checking that API responses are read and handled correctly, and that the communication with relevant API endpoints works as expected.
Copy linkReal-world test scenarios in Sandbox UI
You can use Enode’s Sandbox UI to create and simulate real-world scenarios with virtual assets. The state of virtual assets in the UI is always accurately represented in the Enode API, and updates to asset data are sent to you in webhook events—please see our guide to Sandbox to learn more.
Below are some ways to use the Sandbox UI to simulate scenarios you will see in the real world and prepare your integration for these cases. The examples below are for EVs and batteries, but parallel scenarios can be simulated across all asset types.
Copy linkHappy path linking
- Create a new virtual asset, making sure to select that the asset is Not linked to a user
- Select “Virtual” to see your virtual assets. Open the newly created asset and note its email & password
- Start a new Link UI session
- Use the email and password from Step 2
- Continue the flow
Copy linkWrong username/password and linking failure
- Follow steps 1-3 in “Happy path linking”
- Open Link UI
- Enter credentials that are not associated with any virtual asset
- Close Link UI
Copy linkFully charging a vehicle
- Ensure you have an EV asset already linked to a user
- Open the linked device in the Sandbox UI
- Set the power delivery state to
Plugged in: Charging
- Increase the battery level
- Repeat step 4 a few more times
- Set the battery level to the same value as the charge limit
Copy linkA vehicle disconnects before fully charged
- Ensure you have an EV asset already linked to a user
- Open the linked device in the Sandbox UI
- Set the power delivery state to
Plugged in: Charging
- Increase the Battery level
- Set the power delivery state to
Unplugged
Copy linkConfirming an action
After creating an action, you must edit the virtual asset in Sandbox UI so that the device matches the action's expected state. This example shows how to confirm a battery action, but the same principle applies to HVACs and chargers.
- Ensure you have a battery asset already linked to a user
- Open the linked asset in the Sandbox UI
- Set its Operation mode to anything other than
EXPORT_FOCUS
- Send an API request to set the operation modeAPI to
EXPORT_FOCUS
- An action will be returned to you. In Sandbox and the real world, actions remain in
PENDING
until the state of the battery changes
- An action will be returned to you. In Sandbox and the real world, actions remain in
- In the Sandbox UI, change the operation mode to
EXPORT_FOCUS
- Observe the effect on the earlier action you created
Copy linkFailure to control a battery (already in mode)
- Ensure you have a battery asset already linked to a user
- Open the linked device in the Sandbox UI
- Set its Operation mode to
EXPORT_FOCUS
- Send an API request to set the operation modeAPI to
EXPORT_FOCUS
Copy linkFailure to control a battery (timeout)
- Ensure you have a battery asset already linked to a user
- Open the linked device in the Sandbox UI
- Set its Operation mode to anything other than
EXPORT_FOCUS
- Send an API request to set the operation modeAPI to
EXPORT_FOCUS
- Wait 20 minutes
Copy linkTesting with real devices
Testing with real devices is the natural next step after Sandbox testing has been concluded. When testing with real devices we recommend having two separate Enode production clients. One staging environment to test your functionality with a real device prior to launching, and one live environment which is tied to your live app.
Copy linkStaging environment
The staging environment is where we recommend initial testing with real devices before launching the product or feature in your live app. We recommend performing these tests with devices you have access to yourself. The purpose of these tests should be to validate that the experience and functionality of the new product or feature is sufficient to proceed with a soft launch in your live environment.
Copy linkGetting access to real devices
It can be challenging gaining access to real devices which you can use to test your new features and products in a staging environment. Our primary recommendation is to use devices owned by your organization, or employees in your organization, to conduct this initial testing. This gives you full control of the device and the actions taken without potentially negatively impacting the experience of one of your users.
If you do not have access to any devices through your organization or one of its employees, several other options are available to get access to real devices.
- Device rental
- Borrowing a device from friends or family
- Using and end users device, where you have a close relationship
Copy linkLive environment
The live environment is the Enode client which is directly linked to your live application. Once testing in your staging environment is complete it’s time to launch your changes to your end users! As mentioned previously in this section, we recommend launching to real end users quickly, and prefer this over long-running internal test pilots.
When launching to real end users you may choose to initially go for a soft launch targeted at a select group of users. These can for example be users who have opted to be a part of an early release program.
Another option instead of a soft launch is to run a quiet launch, where you make the change available to all users, but with no marketing or push towards end users to activate the functionality. The functionality may also in these situations be somewhat hidden in your app.
With this approach you can launch a feature early with limited exposure to the general public, and increase the visibility and marketing once the feature has been tested by some of your end users. This approach of course only works if the added feature needs to be enabled by the end user itself.