4 ms·
> Why not delete your test methods too and just test in production? This, but unironically. Depending on your use case, any local tests, whether mocked or usi
by BirdieNZ 5y ago
> Why not delete your test methods too and just test in production?
This, but unironically.
Depending on your use case, any local tests, whether mocked or using a swarm of local containers attempting to represent production may be a far stretch from production reality. Put everything behind feature flags and test your contracts, then release to production regularly and test against live data and live services.
- deleted 5y ago[deleted]
- goodpoint 5y agoYou don't test in production. By definition, prod is what you care about and don't want to break. This is what preprod is for: an environment that stores, receives and processes the same data as prod. It replicates prod as closely as possible and errors or unexpected differences are investigated. Then there are rolling deployments in prod... [and you don't need containers at all]
- BirdieNZ 5y agoCheck out https://copyconstruct.medium.com/testing-in-production-the-safe-way-18ca102d0ef1 https://copyconstruct.medium.com/testing-in-production-the-s... Basically, preprod and any not-prod environments cannot ultimately perfectly reproduce prod, and in a sufficiently complex system, the failure states cannot be predicted in a replicated environment. Instead, using strategies like rolling deployments, you can test on the actual environment you want to validate. If set up properly, it doesn't really risk breaking prod.