Translation tests without getters

[51-code]

Description Translation tests are for checking that the parse tree is translated correctly, namely, that the Step objects are initialized correctly. Currently the tests are done by creating a parse tree, visiting it, and then asserting that the resulting Step object has correctly initialized variables. This is done by having getters in the Step-classes, which is against Elegant Object principles.

Example of a Teragrep translation test utilizing getters: final TeragrepStep cs = ct.teragrepStep; assertEquals(AbstractTeragrepStep.TeragrepCommandMode.EXEC_HDFS_SAVE, cs.getCmdMode()); assertEquals("/tmp/path", cs.getPath()); assertNull(cs.getRetentionSpan());

The translation should probably be tested in a different way, if this is an issue at all. At least returning the correct Step can be easily tested by returning a StepNode in the visit function that gets called in tests and then checking the class of the Step object inside of the Node. However, the initialization of the Step might be more difficult to test.

[kortemik]

is commandMode final in TeragrepStep? if yes then it could be public final?

[51-code]

It isn't final but it certainly should be. However, commandMode is going to vanish in my refactoring of #28. Perhaps using public final variables and getters for non-final variables is the answer. I think that maybe getters are okay here as the reason is to just use them in unit testing. Unit testing shouldn't necessary test values of private variables, but here they happen to be the result of the parser translation which should be tested. So this is kind of an exception of an exception type situation.