FlatPack
[root]/PZFileReader/src/test/java/net/sf/pzfilereader/parserutils
| Author | Changes | Lines of Code | Lines per Change |
|---|---|---|---|
| Totals | 46 (100.0%) | 675 (100.0%) | 14.6 |
| Paul Zepernick | 20 (43.5%) | 351 (52.0%) | 17.5 |
| Benoit Xhenseval | 26 (56.5%) | 324 (48.0%) | 12.4 |
Renamed remotely
0 lines of code changed in:
Created PZMetaData that removes the use of some magic keys in a map
This also provides a bit more semantic in the use of meta data.
The old code is simply commented out or deprecated for now.
104 lines of code changed in:
More unit tests...
0 lines of code changed in:
added unit test for case sensitivity
36 lines of code changed in:
adding more tests
6 lines of code changed in:
added test for empty tabs which is currently failing
3 lines of code changed in:
added test method in that was accidentally removed while combining with bx tests
31 lines of code changed in:
added a couple new checks
2 lines of code changed in:
copied over from bx test cases
20 lines of code changed in:
added some unit tests for pzconverter
11 lines of code changed in:
added a couple new test with spaces as the delimiter. Removed unused imports
4 lines of code changed in:
unit tests to Strip non numeric chars for doubles and longs
22 lines of code changed in:
Paul, some interesting new methods, the BX parser (sorry about the name) seems to be significantly faster than the current one when there are NO qualifiers, If there are qualifiers, it is reasonably faster. But the interesting bits start when I created a new method that uses a StringBuffer rather than using "chunks".
The new method is flying when there are qualifiers all over the place... but is slower (albeit not slower than the current one) when there are no qualifier... and that is a bit of a mystery... anyway... getting too late... Have a look and let me know.
5 lines of code changed in:
do not use null for empty fields, use an empty String.
8 lines of code changed in:
modified the last check in testSomeExtremeCases()
it appears that it should have 2 " in the result of the parse
Benoit, please lmk if this is incorrect.
3 lines of code changed in:
Paul, I've added some basic tests for null, empty, ",,," kind of things. I've also had a go at a parser, the regular expression is a dead-end or will become **extremely** complex due to our special and whacky cases... The basic tests make quite a few things break in the current version. I'll run a couple of speed tests to see where we're going...
21 lines of code changed in:
One more funny test....
1 lines of code changed in:
I have added a few very basic tests and they all seem to fail... Paul, could you investigate? thanks.
9 lines of code changed in:
added a few more tests.
51 lines of code changed in:
first fixed width test
36 lines of code changed in:
(14 more)
