Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to be confident that Python 2.7.10 Doesn't break my Python 2.7.6 Code?

To simplify my work I want to migrate from Python 2.7.6 To Python 2.7.9/2.7.10.

I need to justify that my Python 2.7.10 Will not break my software "working" with Python 2.7.6

I followed the steps describe in porting python 2 to python 3

  • Increase my test coverage from 0 to 40%
  • run pylint (no critical bug)
  • Learn the differences between Python 2.7.10 And 2.7.6 < I read the release notes

I can't be sure 100% that my code will not break, but how can I be confident?

For example, should I have to look at all the Core and Builtins bugs fixed between 2.7.6 And 2.7.10 And search into my code if we use those methods?

Does exists a better strategy?

100% code coverage is a good solution, but it may be harder to obtain than 50% coverage + 100% code using modified methods between 2.7.6 And 2.7.10 Are tested.

like image 991
Guillaume Vincent Avatar asked Jul 03 '15 07:07

Guillaume Vincent


2 Answers

It is a very minor Python update that almost certainty won't break anything, even the without the above mentioned steps (Python 2 to Python 3 migration is a different matter entirely).

As to proving it, well, no amount of statical checking and reading the release notes with help, since all it will tell you, is that almost certainly it is backward compatible (which is the initial guess anyway).

A possible approach would be to reproduce your production environment with Python 2.7.10 in a virtual machine (valgrind, etc can help there) and check if everything runs as expected. No way around running it to be 100% sure.

Increasing coverage is a good idea. By itself though, even full coverage run with Python 2.7.6, doesn't tell you whether it will break with Python 2.7.10 or not.

like image 115
rth Avatar answered Oct 20 '22 00:10

rth


My answer does not apply only to Python, but to software development in general.

First of all, as someone already stated, Python 2.7.10 is "just" a bug fixing release - this means that all regression tests are passing and that no backward incompatible changes are included. This also guarantees that a function signature does not change, therefore your code is likely to be working. Due to Python source code high coverage, it's also possible to say that even if a bug fix might have introduced a bug, this had been covered with regression tests - so either the bug is new or it was not covered by regression tests (the first does not imply the second).

In addition, having 100% coverage is technically not always possible - 90-95% is generally the way to go. And if that's not enough, you might try different scenarios on a local environment as suggested by rth.

However, consider going through your libraries/modules imported and check if they all support Python 2.7.10. If not, it doesn't mean that your project won't work, but it could happen that if you are using some low-level C libraries they might break - so be careful especially there.

In general, I suggest you to go through the changes and through the imported libraries. Adding coverage is always good - not just to update to a new version - so I join other users in saying that you should definitely increase your coverage.

like image 29
Markon Avatar answered Oct 20 '22 00:10

Markon