3 ms·
But you wouldn’t want to develop in that environment, right? You do integration testing in it, but development should largely happen in small modules, with unit
by erikpukinskis 7y ago
But you wouldn’t want to develop in that environment,
right? You do integration testing in it, but development should largely happen in small modules, with unit tests and test data, no?
- __full_pint 7y agoOf course you do that type of testing. The problem comes about when someone does the following: - creates python project - pip install some_package - import some_package Turns out some package was already in the path but a different version - proceeds to test and build with the assumption of some_package @ newer - all tests pass - ships project with requirements of some_package @ newer Someone attempts to use the package but it doesn’t work.
- erikpukinskis 7y agoRight, that’s why you do integration testing (manual and automated) but are you saying therefore you should do all development inside a production environment? That’s what doesn’t pass muster to me. Why should I work on my CSS styles in an environment with the production database? It will be much slower than just working on that package in my desktop environment with just enough scaffolding the code runs. But maybe I’m not understanding your suggestion.
- __full_pint 7y agoOP was referring to containerizing your environment for package development. What does connecting to a production DB have to do with any of that?