TransformExecutor Tests

[f3l1x98]

Closes #415
Note: This PR also includes #462 due to required functionality!

This PR adds tests for TransformExecutor.

[f3l1x98]

Two things I have found:

1. For the sake of creating a table as simple and fast as possible I added an constructor to the Table class. If I overlooked a reason as to why not do that please comment.
2. I wanted to add a test that would check if a row has been deleted because the expression could not be evaluated and I discovered that currently this only happens if there is no expression. The reason for that is that the evaluateExpression function throws assertion errors in case there is an issue which are not caught inside the TransformExecutor#doExecuteTransform. Is that intended, or should I add a try catch? (Because the logged error sounds like it should also handle the exceptions)

@georg-schwarz @rhazn

[georg-schwarz]

Two things I have found:

1. For the sake of creating a table as simple and fast as possible I added an constructor to the Table class. If I overlooked a reason as to why not do that please comment.
2. I wanted to add a test that would check if a row has been deleted because the expression could not be evaluated and I discovered that currently this only happens if there is no expression. The reason for that is that the evaluateExpression function throws assertion errors in case there is an issue which are not caught inside the TransformExecutor#doExecuteTransform. Is that intended, or should I add a try catch? (Because the logged error sounds like it should also handle the exceptions)

Could you post a link to the file?
Assertions should never fail, they point to a bug.
If a user led to the mistake, there should be an exception IMO.

[f3l1x98]

Two things I have found:

1. For the sake of creating a table as simple and fast as possible I added an constructor to the Table class. If I overlooked a reason as to why not do that please comment.
2. I wanted to add a test that would check if a row has been deleted because the expression could not be evaluated and I discovered that currently this only happens if there is no expression. The reason for that is that the evaluateExpression function throws assertion errors in case there is an issue which are not caught inside the TransformExecutor#doExecuteTransform. Is that intended, or should I add a try catch? (Because the logged error sounds like it should also handle the exceptions)

Could you post a link to the file? Assertions should never fail, they point to a bug. If a user led to the mistake, there should be an exception IMO.

I am talking about this commit (seems like I already added the try catch 😅 ): 28b5836

Because without this commit any exceptions thrown inside evaluateExpression will propagate through the whole stack up to the tests (or the system somewhere higher up in production).
Not sure why I wrote assertion errors instead of exceptions in general...