nsoft commented on PR #2017: URL: https://github.com/apache/shiro/pull/2017#issuecomment-3217475209
Well if you don't have good confidence in your test coverage that's too bad. I don't know why tool generated changes are better/simpler to review and inspire more confidence than human generated changes. I can see a tool having benefits generating the changes **faster**, but I would not trust such changes nearly as much as changes by a human, and feel the need to review them even more closely. The tool will be good where you've done things that are regular and expected (from it's perspective), and very likely go badly wrong where you have key custom idioms, design choices or places where you intentionally did things uniquely. I would think that this is especially problematic if the tool is changing both tests and code, because you could wind up with the same wrong conversion in both places causing a test to pass incorrectly, whereas compile first then fix tests (by a human) means that there is zero chance of being unaware that a test was perturbed. One has to at least look at and think about what failed, because the first pass (make it compile) made all the tests fail before any were made to pass. However as I've said, it doesn't matter how you ultimately support EE10+ & Jakarta namespaces, just that you do :). If I can help, let me know. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
