primefaces - How to update JSF web application components without broking it's current functionality? -
i have large web application (100+ jsf pages) using richfaces 4.1.0. trying new features offered richfaces 4.3.0 (rich:placeholder, example). brings me question: if want use new richfaces version, how can know if it's safe upgrade?
i think unsafe because of different factors: old bugs, new bugs, changes in functionalities, code written (that not good...), ...
however, know, how approach kind of problems in production project. avoidable constructing "good" test set using junit, mockito, arquillian or other? or maybe letting application best approach once has been delivered? in case, never upgrade jar in it, (avoid possible)?
in specific problem, richfaces team has developed internal framework called cdk provides components independence in order facilitate modularization. means can take rich:placeholder component , create single jar it. have add new jar our application. avoid upgrading main richfaces jar. should work fine in case because rich:placeholder new component, not work if trying upgrade component exists already.
i think same question applies other frameworks: primefaces, icefaces...
what suggestions on how afford upgrading issues?
regards,
there 3 approaches kind of upgrade , depends on fits capabilities of team, budget , time.
1) automated web testing
a useful web testing framework selenium can allow record web application interaction latest stable release, , playback recorded interaction on prototyped version of web application.
the learning curve here such technically skilled qa analyst should able walk through independent recording verify each documented requirement.
2) modularization upgrades
the cdk idea sounds great risk averse way upgrade jsf framework on time. best approach if time , manpower isn't there.
3) qa brute force
the quality assurance team manually walk through test cases requirements , verify test cases still passing. labor intensive first approach, next time front end library or framework upgraded entire process have repeated.
the netscape method
netscape famously known downfall during browser wars in 90's. brought them down philosophy on testing , qa. believed users should qa, stupid belief because users form 90% of opinions on product based on first impression.
this method has developers brute force upgrade until compiles, simple smoke testing, , when seems okay, release production , wait user feedback determine bugs. don't recommend approach unless have non-critical application , captive user base.
Comments
Post a Comment