Testing Greengrass Components Before Deployment with IPC

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.