我有一个大型web应用程序(100+ jsf页面)使用RichFaces 4.1.0。我正在尝试由RichFaces 4.3.0提供的新功能(例如rich:placeHolder)。这给我带来了一个问题:如果我真的想使用新的RichFaces版本，我怎么知道升级它是否安全?
我认为它是非常不安全的，因为不同的因素:旧的bug，新的bug，功能的变化，已经写好的代码(不一定是好的…)，…
但是，我想知道，在生产项目中，你们通常是如何处理这类问题的。是否可以通过使用JUnit、Mockito、Arquillian或任何其他方法构建一个非常"好的"测试集来避免?或者在交付后，让应用程序保持原样将是最好的方法?在这种情况下，我们将永远不会升级其中的任何jar， (尽量避免)?
在这个特定的问题中，RichFaces团队开发了一个名为CDK的内部框架，它提供组件独立性以促进模块化。这意味着我们可以取rich:placeHolder组件，并为它创建一个单独的jar。然后我们必须将这个新的jar添加到我们的应用程序中。这避免了升级所有主要的richfaces jar。在这种情况下，这应该可以正常工作，因为rich:placeHolder是一个新组件，但是如果我们试图升级一个已经存在的组件，它将无法工作。
我认为同样的问题也适用于其他框架:Primefaces, Icefaces…
你对如何解决这个升级问题有什么建议?
认为,
这种升级有三种方法，这取决于最适合您团队的能力，预算和时间。
1)自动Web测试
像Selenium这样有用的web测试框架可以让你记录web应用程序与最新稳定版本的交互，并在web应用程序的原型版本上回放记录的交互。
这里的学习曲线是这样的，技术熟练的QA分析师应该能够通过独立的记录来验证每个文档化的需求。
2)模块化升级
CDK想法听起来像是一种规避风险的好方法，可以随着时间的推移慢慢升级JSF框架。如果没有时间和人力，这可能是最好的方法。
3) QA Brute Force
质量保证团队将基本上手动遍历所有需求的所有测试用例，并验证测试用例仍然通过。这和第一种方法差不多是劳动密集型的，但是下次升级前端库或框架时，整个过程将不得不重复。
网景方法
网景公司因在90年代浏览器大战中倒闭而闻名。导致他们失败的是他们的测试和QA理念。他们认为用户应该是QA，这是一个愚蠢的信念，因为用户对产品的看法90%是基于第一印象。
这种方法基本上是让开发人员强制升级，直到编译完成，做简单的冒烟测试，当一切似乎都没问题时，将其发布到生产环境，等待用户反馈来确定bug。我不推荐这种方法，除非您有一个非关键的应用程序和一个固定的用户群。