Apply tests to test class

[martinmladenov]

Description of changes made

Allow the user to pick a test class to apply the selected tests to, and append the chosen test cases to the end of that class

Why is merge request needed

Applying the test cases generated via TestGenie is a very nice feature so that the user doesn't have to copy them manually.

Other notes

Closes #45

[martinmladenov]

@jzelenjak Thanks for the comments. What exactly do you mean by package-private fields - what is being marked as an error? Could you be a bit more specific?

About appending tests multiple times: I think that this is up to the user, since we shouldn't limit them in what they are allowed to do (and doing so would be very complex anyways). They could end up with equivalent tests by running the plugin multiple times as well, but there's not much we can do to prevent them from adding them to the test suite. We also shouldn't simply mark tests that have already been added to a file as "added" and never add them again, since a user could accidentally delete one of the tests they just added and might want to add it again.

Creating a test for class might indeed be a good idea, but we should be careful, since it gives users the impression that TestGenie can generate a complete test suite for the whole class, which is not the case. Tests should always be manually reviewed and augmented by a developer.

[jzelenjak]

@jzelenjak Thanks for the comments. What exactly do you mean by package-private fields - what is being marked as an error? Could you be a bit more specific?

About appending tests multiple times: I think that this is up to the user, since we shouldn't limit them in what they are allowed to do (and doing so would be very complex anyways). They could end up with equivalent tests by running the plugin multiple times as well, but there's not much we can do to prevent them from adding them to the test suite. We also shouldn't simply mark tests that have already been added to a file as "added" and never add them again, since a user could accidentally delete one of the tests they just added and might want to add it again.

Creating a test for class might indeed be a good idea, but we should be careful, since it gives users the impression that TestGenie can generate a complete test suite for the whole class, which is not the case. Tests should always be manually reviewed and augmented by a developer.

By package-private i mean if you don't put an access modifier, then it is only visible within a package, meaning that if in this case you put your tests into a file in another package, there will be errors, because they cannot be resolved

Imports are also broken, but that is fine in my opinion.

I agree with you about the second paragraph.

About the last point, i still think we have to add it, maybe in another issue, but otherwise it will be confusing to the user which we want to avoid.

[martinmladenov]

By package-private i mean if you don't put an access modifier, then it is only visible within a package, meaning that if in this case you put your tests into a file in another package, there will be errors, because they cannot be resolved

We can't really do anything about that, sadly - this is a consequence of allowing the user to insert test cases into any of their test classes. Preventing that would be very difficult and would likely be quite confusing to users if some of their test classes simply don't appear. In any case, it would be easy for a developer to fix such issues once they insert their tests.