https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
t
In my understanding, for lambdas if you want to manually test it, most people test it on the cloud it self (manual testing). https://medium.com/faun/how-to-effectively-test-aws-lambda-with-a-simple-strategy-46bda656200e
This article shows how to maybe replicate it locally. We use the pulumi kubernetes to run our apps locally by using the local context and deploying an image, mount a volume, curl it to test etc.
n
Yeah. The tricky bits for local are all the other dependencies... like if something is gonna write out to SQS, that's tricky. I've seen local stack as an option, but not sure how that works with pulumi
I guess I have this goal of being able to work when I have no internet connection... But perhaps that's unrealistic. In reality I can't remember the last time I did real development without internet. Usually when the network goes down I take it as an excuse to do something else :P
t
So, I think with local stack, I used it with a docker compose such that it is in the same network with my app, if you use kubernetes, im thinking you can just create a configIp type service locally with the ports corresponding to each service (expose multiple service ports) you should be able to run it. Pulumi has a great K8s provider.
Copy code
const ingress_service =  new k8s.core.v1.Service("localstack", {
        metadata: {
            labels: deployment.spec.template.metadata.labels,
            namespace: "manual-test"
        },
        spec: {
            type: "ClusterIP",
            ports: [{name: "sqs", port: 4576, targetPort: 4576, protocol: "TCP" }, [{name: "S3", port: 4572 targetPort: 4572, protocol: "TCP" }],
            selector: appLabels
        },
    },
    {provider:provider}
);
so basically in your deployment object just pass in the local stack image, and then in your service object expose the ports you want to run,.
@nice-cat-91582
I have not tried this but this seems plausible.
ports correspond to these, https://github.com/localstack/localstack
l
For point 2, the aspect of 
unit testing
dissappears if you try to replicate your stack locally. TL;DR: Dissect your problem to smaller problems and unit test the smaller chunks Why not dissect your setup in a few unit tests: 1. unit test the function or method that transforms the Lambda input (e.g. a JSON) to the required input for the PDF generation 2. unit test a separate function or method which given some input creates a PDF. Validation e.g by http://www.pdfunit.com (Haven’t used my self but was the top Google search result) 3. unit test the post processing, e.g. sending the PDF as an email in a mocked setup. You no longer need Docker, replicated setups and alike…
💯 1
t
I agree, I would think unit testing would be the best as well.
n
yeah, it's just that unit testing the visual bits of PDFs is a fair bit difficult. Once I lock in the rendering I can probably just test the inputs to the PDF generator, and trust that the renders will always be fine
and probably can hack around the previewing bit during development... have the renderer output to a local file, just while I'm doing the initial build
Open in Slack
PreviousNext
Powered by