Comment by bizzleDawg | Hacker News Reader

Comment by bizzleDawg | Hacker News Reader

Eeek. Doesn't sound like you're being unreasonable in your expectations at all!

I've been a small business owner, and a software contractor, so I've seen a fair few medium/large python codebase of varying age and quality.

To address your points from the ~10 codebase I've worked on in recent memory:

- Code review: Always in place, though often the CTO has a tendency to merge without review on evenings/weekends

- Test Coverage: Often a challenge - or rather tests are there for coverage, but are of poor quality and don't really assert anything that useful

- Your suggested normal workflow _is_ the normal. Sometimes there's been a dedicated QA team that verifies the changes as seen by the end user too.

- Deployment: Yep. Heroku or k8s have been common, but at least some form of 1-click deploy/promote

Perhaps I've just been super lucky! There are often still major problems in the codebase and refactoring/rebuilding needed to address the challenges, as well as resistance of the existing team to truly change their mindsets to address the problem v.s. the band-aid (or instant gratification) of a quick fix.

Don't give up the fight!

Adequate test coverage is hard without rebuilding from scratch. Hard to expect in a big, old company. Except when a huge codebase have to be rebuild because python2 have to be replaced (one of our software provider is in this case).

Out of all the items on the list (code reviews, CI, etc), it seems like test coverage would be the simplest to improve? Assuming it has a test suite at all, use one of the various test coverage scanners (simplecov, coverage.py, etc) and check the output for a file with a low % of lines covered. Then write one or more tests to cover the edge cases not yet tested.

It's a purely mechanical process unlike most of the other problems which depend on changing the behaviour of people in different departments and/or with more influence than you.

Depends, code that was not written with testing in mind can be very difficult to cover without some major refactoring.

Adding the first tests can be a slow and painful process.

Now, once you have those few tests? Yep! Add a few tests along the ones for the new functionality every time you touch a piece of code or pick the low hanging fruit every now and again and you can get to a useful test suite in no time.

"It's a purely mechanical process" - I thought on this for a while. I think if your testing is purely mechanical then you're probably not getting much value from it. Good tests need to be "smarter" than the code they are testing in a way.

Unit testing, for coverage (as a vanity metric) can be mechanical maybe, but integration tests are the way more valuable ones (for the most part) and way more complex.

Reply on news.ycombinator.com