Separate unit tests from integration test 2.0 about jadb HOT 4 CLOSED

But only public classes/functions are ever tested by design. Which class would you like to test? Please explain a bit more about this "problem".

from jadb.

For example - see this cross-repository comparison of #38.

Shortly - I want to implement getprop command of android device.

To make this feature testable I separated this functionality in 2 parts:

• executing shell command
• parsing inputstream as a result.

This allows to test most complicated part without overriding executeShell method
Not to put garbage in module interface only actual getprop method is public and parseProp is not.
To actually call this method I need package level access which can be achieved only if test have the same package name as testable class

P.S. Unit tests philosophy (as I understand - I may be wrong) is to test as little parts of the system as it is possible to reduce interference of different bugs from different modules. So if part of the system is implemented in package local class - it is no problem to test it alone even it is not visible for clients

from jadb.

I see, I think it would be a much cleaner solution to just mock the public interface. That way you test behavior rather than implementation. The latter is less likely to change, and if it does change you want to change the test. Pros:

• Calls the function exactly as a user of the library would.
• You can also assert what the actual command was, e.g. getprop
• No need to expose internal (default visible) methods.
• No needs to mix integration and unit tests.

Disadvantage:

• You will need to extend the FakeAdbServer to also handle executeShell output. I can probably help out with this.

from jadb.

Plan B - Just make the getprop() function public

from jadb.