3 ms·

They go hand in hand. If you write tests, but they're not run after each dev commits changes, you're not testing those changes for regressions. If you have CI w

They go hand in hand. If you write tests, but they're not run after each dev commits changes, you're not testing those changes for regressions. If you have CI without tests, what is the CI going to do? It could still be used for packaging executables/distributions, and possibly orchestrating deployments, but it sounds like that's not your goal. Save yourself some grief and use a service like CircleCI, it provides isolated (Docker) environments that are spun up per test run. It supports many languages and background services (like databases). As for writing tests, you would be best to start writing them at a "system boundary". This might take the form of sending HTTP requests to your endpoints and parsing the response.

ajeet_dhaliwal 9y ago
I agree that they go hand in hand. In practical terms however it can take a long time to write comprehensive test cases for legacy code, even if only writing integration and system tests and ignoring unit tests. A pragmatic approach would be to write a few tests quickly first. Then implement CI as quickly as possible. After the CI is working end-to-end running the few tests you quickly setup before then you can focus on expanding coverage of testing. Basically, I'd suggest writing only enough tests to test the CI first :-) Then once that's in place you can add tests. One other thing that is important to get right is reporting (at the end of your CI flow, once each build and test run has completed). This will help you keep on top of regression but most notably demonstrate the real value of what's going on with all the work you're putting in now. You don't have contact information in your profile but I wanted to add that I've worked in the role of a software engineer focused on automation (CI and testing) at large tech companies and I felt so strongly about how important the reporting aspect of this is that I started a web-based reporting service that is growing in usage. Check my profile for details, I'm the founder, contact me with any questions or feedback.

ajeet_dhaliwal 9y ago

I agree that they go hand in hand. In practical terms however it can take a long time to write comprehensive test cases for legacy code, even if only writing integration and system tests and ignoring unit tests. A pragmatic approach would be to write a few tests quickly first. Then implement CI as quickly as possible. After the CI is working end-to-end running the few tests you quickly setup before then you can focus on expanding coverage of testing. Basically, I'd suggest writing only enough tests to test the CI first :-) Then once that's in place you can add tests. One other thing that is important to get right is reporting (at the end of your CI flow, once each build and test run has completed). This will help you keep on top of regression but most notably demonstrate the real value of what's going on with all the work you're putting in now. You don't have contact information in your profile but I wanted to add that I've worked in the role of a software engineer focused on automation (CI and testing) at large tech companies and I felt so strongly about how important the reporting aspect of this is that I started a web-based reporting service that is growing in usage. Check my profile for details, I'm the founder, contact me with any questions or feedback.