Java Unit Testing – How Have Guava Unit Tests Been Generated Automatically?

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.

Firstly, you should not use profiling to determine performance. Profiling is intended to be used in order to identify the parts of your program which take the most time. When measuring performance, we only care about the speed of the whole program taken together. Profiling in that case only skews results. Instead, performance should be tested by benchmarks. The program processes some task, and we just measure how long it takes.

Secondly, you don't pass or fail performance tests. What we want to do is identify when something has made the program run slower. By running a benchmark against different revisions, you can easily obtain performance data for each revision. From there is would be fairly simple to automatically raise a warning on significant performance degradations.

http://speed.pypy.org, has done something like this. You can see the performance of PyPy as charts which show its performance. You can look at each benchmark and how it has changed over various revisions. You can actually see some revision which markedly decreased performance but were later fixed.