This message was deleted.
# developer-productivity-engineering
s
This message was deleted.
a
That could be a talk by itself. We have local testing of course, E2E and integration and unit tests. We also have tests that run on every revision to a diff, so you can push changes up to your diff (even if it's not published) and then the infrastructure will run a modest test suite for you. There are on-demand ad-hoc options that we can initiate for a diff beyond the basic suite, and we can also run the full land-blocking suite in a "dry-run" mode.
❤️ 1
a
Great stuff. Thanks for taking the time to do the talk as well, really appreciate the insights, and color. Could you dive a bit deeper into the local testing aspect? I assume this means the ability to generate builds locally itself, and wondering how this can happen more or less fast each time for what I image is a huge build or multiple builds.
a
@Andrew Louis in a word, caching. We only rebuild artifacts when we absolutely have to and we maintain a "stable" point that trails master by a couple hours at any given time. So long as you're working from the stable point, local builds are quite fast. This enables us to locally apply just about anything from our test suite and do local validation of changes.