7 ms·

Hopefully there is a comprehensive set of integration and acceptance tests to verify that the output of the new tool matches the output of the old tool, bugs an

• orf 10y ago
  Isn't that a null point? If they don't exist then this endeavour is dangerous no matter the method you go about it - translating perl to python doesn't ensure its a 1-1 mapping functionality wise, and if you're going to rewrite it in idomatic python anyway....
• mnm1 10y ago
  Run the old tool, run the new tool, compare outputs. If you can't do this, you shouldn't be rewriting anything.
  • JoshTriplett 10y ago
    If you don't have a comprehensive set of test inputs, then "compare the outputs" doesn't suffice. (If you do, then by all means, take that approach.)
  • majewsky 10y ago
    I do this a lot (end-to-end tests that just `diff` the results from the current code with the expectation that I previously committed into the repo), and it makes one appreciate how much work it is to make a program's output deterministic. When you look around some of my code, there's a lot of loops over maps/dicts/hashes where, instead of iterating over the map directly, I first gather the keys, sort them, and then iterate over these to ensure that the test is deterministic.
    • tofflos 10y ago
      Plus one for deterministic software. It's an incredibly useful property when you want to test something. Particularly when doing major version upgrades and when replacing entire systems. Unfortunately strict determinism and test coverage often go hand in hand. Either the developer gets it or (s)he doesn't. Fortunately you often do get a least a moderate level of determinism even from the most awful software.