- Più recenti
- Maggior numero di voti
- Maggior numero di commenti
Hi. If you get your component into a unit test harness, you could mock the IPC calls and achieve a lot of automated test coverage. A very small example of IPC mocking:
- Code under test: https://github.com/awslabs/aws-greengrass-labs-component-for-home-assistant/blob/main/artifacts/secret.py
- Tests: https://github.com/awslabs/aws-greengrass-labs-component-for-home-assistant/blob/main/tests/test_artifacts_secret.py
If you are prepared to deploy the component locally (on your developer machine) to a Greengrass instance, you could also achieve integration testing of the component (assuming the component doesn't have dependencies on hardware that is not available on your developer machine). You could:
- Use the Greengrass CLI to deploy your component locally (quickly, easily and repeatedly while developing).
- Configure your local Greengrass to interact with local client devices by deploying the MQTT broker (Moquette), MQTT bridge, Client device auth and IP detector components.
- Configure the MQTT bridge topic mapping to relay the appropriate topics from Moquette (LocalMqtt) to PubSub and PubSub to Moquette (LocalMqtt). This blog is also helpful.
- Use an MQTT client of your choice (such as mosquitto_pub and mosquitto_sub) to connect to Moquette as a client device, and do pubsub with your component via the MQTT bridge.
- You could automate integration testing by getting this into a test framework like Cucumber. And go further by getting this all into a CI/CD pipeline.
On my development GG v2 device I ran a basic component that logged the env variables: AWS_GG_NUCLEUS_DOMAIN_SOCKET_FILEPATH_FOR_COMPONENT SVCUID
I then set these in my .env file and passed them to the component I was developing while greengrass was also running on the same machine. the greengrass IPC then works as expected outside of an active deployment.
Contenuto pertinente
- AWS UFFICIALEAggiornata 2 anni fa
- AWS UFFICIALEAggiornata 2 anni fa
- AWS UFFICIALEAggiornata 10 mesi fa