developing code, you regularly must test it before pushing to the event or production environment. Nevertheless, waiting for a deploy with GitHub actions, or CDK stack deploys with CDK, is time-consuming.
Such time-consuming tasks kill iteration speed, which is a critical factor if you wish to develop code effectively. It is because it’s essential test your implementations properly to make sure they work. Then, after each change, it’s essential test it again.
With the newest coding agents, developing full local testing scripts is super fast, and something I do every single day as I write code as an information scientist.
In this text, I’ll take you thru why it’s essential create an efficient local testing setup by running a Docker image and sending test events. I’ll also show how I do it myself, and the way it helps me change into a more efficient engineer.
I’ll mostly be talking about work with Infrastructure as Code (IaC), because that’s mostly what I’m working with on a day-to-day basis. Nevertheless, the concept of efficiently running your code locally applies to all programming.
Why it’s essential run code locally
Firstly, I would like to cover why we’d like to run code locally. The straightforward answer is that:
Iteration speed is some of the essential points for efficiently getting working code to production
The faster you possibly can iterate in your code, the higher. While you develop latest functionality (or fix old functionality), you wish to quickly test if it really works, after which iteratively fix the code until it really works as intended.
If you’ve gotten to attend 5-Quarter-hour on your code to deploy before testing it, you’ve gotten a major problem. Each time you’re not capable of one-shot an issue, you waste 5-Quarter-hour simply waiting for the deploy.
As an alternative, you need to run your code locally. For instance, in the event you’re working with IaC, comparable to AWS CDK, you possibly can construct and run Docker images locally, essentially replicating the production environment, but on your personal computer. This manner, the iteration loop is easy, and the time it takes to construct the Docker image and run the code.
Constructing the Docker image is generally very fast, considering Docker caches previous builds. Thus, most of your time might be spent running the code with test input and verifying the output is as expected.
In the event you’re working on an online application, you need to (and doubtless are already), running the appliance locally, before deploying your code. There needs to be no difference when working with IaC.
Tips on how to develop locally as if it were a production environment
A vital aspect when developing locally is that you simply’re capable of closely replicate the production environment. In the event you’re writing IaC, constructing Docker images, and running the Docker image locally:
You’re testing with the very same code, with the identical input paths, and in the event you mirror your .env file to the production .env file, you furthermore may mirror the entire variables. Thus, running Docker images locally is the solution to go in the event you can do this.
Create local scripts with coding agents
Before the discharge of coding agents like Cursor and Claude Code, it was often a tedious task to establish code to run every little thing locally. You needed to construct the Docker image accurately, set it to run together with your .env file, and so forth. Or it is advisable to run your code locally as a FastAPI server as a substitute, wherein case you faced similar challenges.
This just isn’t a problem anymore, nonetheless. To start out running locally, I often provide Cursor the next instruction:
Create a shell script for me to run this code locally. The shell script
should run the docker image, and have an optional --build flag, which builds
the docker image before running it. The docker image should load environment
variables from the .env file.This creates an efficient shell script you should use. I just like the optional –tag, since it’s sometimes time-consuming to construct the Docker image, and I don’t at all times need to construct it before running.
Also, the next aspects allow me to run the script easily:
- I never store actual secrets in .env. I only store secret references, which my code then picks up from AWS Secrets Manager. Thus, I can push my env file with none worry of leaking secrets. Moreover, this makes it easier for others to run the scripts as well when pulling the code from GitHub
- I create one other file with test events, where I can easily send events to the running Docker image. This manner, I can easily check the input and output
- I deploy the testing scripts to Git, so everyone else also has access to them. This includes the env file as mentioned, because it doesn’t contain any secrets
Now you’ve gotten the precise setup it’s essential run and test your code locally. Each time you make changes, you rebuild the Docker image and send the test events, ensuring that every little thing is working as intended.
I like to recommend establishing these local testing scripts for all of your repos and pushing them to Git for sharing. Gaining access to these scripts will make your entire team more efficient as programmers.
Further tricks to run locally
I also wish to share two additional tricks to be much more efficient, given these local testing files:
- Run and test Docker image with pre-commit hooks
- Give your coding agent access to those scripts
Pre-commit hooks
Pre-commit hooks are code that runs before every commit to git. Typical pre-commit hooks include:
- Run for formatting
- Run for type safety
- Run to be certain that all tests pass
Having a pre-commit hook guarantees you always remember to run any such commands before pushing your code. That is incredibly useful and an ideal timesaver. It’s hard for me to count the variety of times I forgot to run black formatting before committing, and the deploy tests find yourself failing 5 minutes later, costing me lots of time.
If constructing, running, and testing on the Docker image just isn’t super time-consuming, I like to recommend also adding this to the pre-commit hooks. This manner, you guarantee that before you push any code, you’ve tested that the code runs in a production environment, and that you simply get the expected output for a given input. Implementing this as a pre-commit hook will likely prevent lots of time in the long run.
Give Cursor access to testing scripts
The second tip is that I at all times provide Cursor and Claude Code access to run my testing scripts. I then tell Cursor to run the testing scripts after making changes, and before ending its current implementation.
Having your coding agent run and test Docker images will vastly increase the quantity of times it’s capable of one-shot an implementation
It will prevent lots of time when your coding agent implements a feature, after which you’ve gotten to manually run and test the Docker image. In the event you now encounter an error, you’ve gotten to stick that into your coding agent, and the cycle repeats until the code is working.
It is a waste of time, and something you need to work hard to avoid. Giving your coding agent access to the testing scripts is actually like handing your coding agent a tool, which strongly improves performance in software engineering tasks. I can’t stress enough how much time this protects me.
Conclusion
In this text, I’ve discussed how you possibly can create realistic production environments locally by creating scripts to construct, run, and test Docker images locally. Doing this lowers iteration speed, which is a critical component of being an efficient programmer. Moreover, I covered how I do that in practice: by prompting Cursor to create the testing scripts, and a few example events I can run on the Docker image. I then give Cursor and Claude Code access to run these scripts, making my programming vastly more efficient.
I consider that having a fast iteration speed is critical for just about all software engineering tasks, and it’s something you need to strive for. Creating local test files and giving your coding agent access to them increases iteration speed rather a lot, which is why I consider that doing so myself has vastly increased my productivity as a programmer.
👉 My Free Resources
🚀 10x Your Engineering with LLMs (Free 3-Day Email Course)
📚 Get my free Vision Language Models ebook
💻 My webinar on Vision Language Models
👉 Find me on socials:
🧑💻 Get in contact
✍️ Medium
