|
So far the testing has found changes for
TRUNK Subversion 17831 icefaces\component\test\java\com\icesoft\faces\mock\test\CompPropsUtils.java icefaces\component\test\java\com\icesoft\faces\mock\test\TestDataProvider.java icefaces\component\test\java\com\icesoft\faces\mock\test\SerializedViewFieldTest.java icefaces\component\test\java\com\icesoft\faces\mock\test\data\MockMethodBinding.java When the test fails, for now we don't want the build failing. Also, I made it stop reporting about deprecation, since it's highly redundant.
TRUNK Subversion 17833 icefaces\component\build.xml icefaces\component\test\java\com\icesoft\faces\mock\test\SerializedViewFieldTest.java These are the main types of changes that were necessary for the test to pass:
Component changes - Make component's saveState and restoreState handle a field - Mark fields that shouldn't be state saved transient, so the test will ignore them - Refactor fields, which are not state savable or Serializable (like other components in the tree, or data from the bean), but that aren't transient Object changes (Objects that the components refer to) - Make Serializable - Implement deep equals(Object), so that deserialized copies of objects can be compared to their originals Test changes - Create test object instances, covering all object types, of the component fields Fixed a bug in the array comparison part of the test, which was counting String[] as not matching, when they actually did.
TRUNK Subversion 17849 icefaces\component\test\java\com\icesoft\faces\mock\test\SerializedViewFieldTest.java The test has been tightened to let less through. By default a failure will now break the build.
Subversion 18072 icefaces\component\test\java\com\icesoft\faces\mock\test\SerializedViewFieldTest.java icefaces\component\test\java\com\icesoft\faces\mock\test\TestDataProvider.java Subversion 18073 icefaces\component\test\java\com\icesoft\faces\mock\test\TestDataProvider.java |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Closed
Major
Test component field state saving
Next, we explored the idea of generating code, for each component class, so that we'd have the best of automatic correctness and fast execution. The problem was that we'd complicate the build process noticeably. As well, it would complicate debugging, since you'd effectivel have two sets of source files and class files, which we thought would be a problem for our users.
There was also the sub-option of code generation, which is class file modification, where we add state saving byte-codes to the class files, without intermediate source files. This still complicates things, and adds a certain degree of black magic, that could cause problems for users.
So, the current solution is to write a solid test platform, to verify the hard coding. It's not as automatic, but is very straightforward, and gives the most flexibility with the greatest simplicity.