Java – How to make automatic tests for GUI

Case: a "module" (in a broad sence, i.e. something having a public interface and possibly also some private inner parts) has some complicated / involved logic inside it. Testing just the module interface will be sort of an integration testing with relation to the module's inner structure, and thus in case a error is found such testing will not localize the exact inner part / component that is responsible for the failure.

Solution: turn the complicated inner parts into modules themselves, unit-test them (and repeat these steps for them if they are too complicated themselves) and import into your original module. Now you have just a set of modules simple enough to uniit-test (both check that behavior is correct and fix errors) easily, and that's all.

Note:

• there will be no need to change anything in tests of the module's (former) "sub-modules" when changing the module's contract, unless the "sub-module"'s no more offer services sufficient to fulfil the new/changed contract.

• nothing will be needlessly made public i.e. the module's contract will be kept and the encapsulation maintained.

[Update]

To test some smart internal logic in cases when it is difficult to put object's inner parts (I mean members not the privately imported modules / packages) into appropriate state with just feeding it inputs via the object's public interface:

• just have some testing code with friend (in C++ terms) or package (Java) access to the innards actually setting the state from inside and testing the behavior as you'd like.

  • this will not break the encapsulation again while providing easy direct access to the internals for testing purposes -- just run the tests as a "black box" and compile them out in release builds.

I mentioned in one of my comments to simoraman's answer that I had thought of a couple of ways to do this. One of my options was similar to the suggestion in Jalayn's answer to created a duplicate project and generate a DLL, while my other idea was to simply link to the files in the project where there was code I wanted to test. While both options could be made to work, they are less than ideal.

In the second case, I'd have a mess of unit dependencies to manage unless I could really tease apart the architecture to minimize dependencies. This is fine for smaller projects, but larger ones could easily become a real mess to manage. My biggest resistance to this option however is the sheer inelegance of it. Sure I could get it to work, but in doing so I effectively need to break encapsulation to test the internals of an assembly directly via source, rather than testing the via the public interfaces, which in my mind is a big no-no. Likewise having an additional project file would mean either duplicating efforts in two projects at a time, or finding a way to add project file settings automatically to two files at a time, or remembering to copy and rename the project field each time I build. This can be automated on the build server perhaps, but would be a pain to manage in the IDE. Again, it can work, but it's a kludge at best, and a nuisance at worse if you get it wrong.

The best way seems to be to do as whatsisname commented to my question, and to simply include the EXE as a reference in the test project. It turns out that an EXE is effectively treated the same way as a DLL in this case, and I am able to access all of my nicely layered classes to test whatever floats my boat.