We Keep Coding

Java - Access private class

I know how to access private variables, but I have the following class that I'm trying to test:
ProcessStatusResult:
#Getter
class ProcessStatusBody {
public ProcessStatusBody(ProcessStatus status) {
this.status = status;
}
ProcessStatus status;
}
#Getter
public class ProcessStatusResult {
ProcessStatusBody body;
...
public ProcessStatusResult(ProcessStatus status) {
body = new ProcessStatusBody(status);
...
}
}
In my test, I need to get the ProcessStatus inside ProcessStatusBody to validate it, but I have no idea how to do that.
Is there a way to use reflection (or some other method) to access this without having to add a getter in ProcessStatusResult for the sake of the test alone?

There are broadly speaking 3 different ways to tackle this problem.
The common way - (ab) use package private.
It's common to stick (unit1) tests in the same package as the code it tests. Different 'source root', same package. You'd have:
src/main/java/com/foo/Whatever.java
src/test/java/com/foo/TestWhatever.java
When you do this, your test code can just 'see' all package private stuff (because, same package).
Some projects would like to highlight this a bit and have an annotation that indicates 'this item is package private for the sake of test code; we would have made it private otherwise', and if you really want to go all-out, you add linter tools that detect any attempt to interact with entities so marked from other source files in the same package (not the test code) and flag it as an error.
These tools are, in my experience, unfortunately not commonly used and I'm not readily aware of linter tools that do this. A somewhat common annotation for this is guava's #VisibleForTesting. It doesn't do anything except serve as documentation (for now - one could write a linter tool that actually checks for style violations, of course).
The uncommon way, reflection and mocking
Test frameworks can do this but it severely hampers productivity. If you want to access your status variable, all you need to do is type body. and hit CTRL+SPACE or equivalent in your IDE and it'll be shown right there, you can just select it, you can CMD+click once you type or auto-complete it to be taken straight to its definition, and if you typo the name, your IDE will red-wavy-underline it.
Replace body.status with something like reflect.getField(body, "status", ProcessStatus.class); and it's a heck of a mess. It's long, ugly, mismatches generics to types (what if status is of type List<String>? List<String>.class isn't valid java. You could use reflection hackery to allow you to assign reflect.getField to anything you please, but now you have no type safety. If you mess up the type, you won't know until you run it. If you mess up the generics, you may not ever know, ouch.
Hence, this isn't great either, and is consequently not used often.
The nuanced way: That's not how it works.
private perhaps just means private. It's not meant for consumption by anything 'external to the source' file and that includes the unit tests. No source file consists solely of 100% private everything - there is some API you're supposed to plug into from 'outside', and test code can get at everything except private (so, package private, protected, and public is all accessible by test code). Test the public API parts, don't test the private stuff - after all, the normal idea behind private is that you're free to mess with these as much as you please, change what they do, change their signatures, all you need to check is what impact that has based solely on what else is in this source file you are looking at.
There is benefit in not having to extend that to: "... oh and you also need to revisit all the unit tests that interact directly with this".
Make an actual public-ish API (package private if you wish, but you write it with the actual intent that code from outside this source file will want to use this feature) and test that. Or, if truly this field is not a detail that even other source files in the same package are meant to know about then do not test it - it's too fine grained a test.
There are upsides and downsides to testing at such incredibly fine grained levels. Generally, that level of fine-grainedness makes tests simpler and more 'localized' (any error the tests catch will be pointing right at the actual problem), but going that deeply means you need a heck of a lot of tests, most tests turn into the trivial, and it creates significant resistance to refactoring - after all, even a simple refactor requires modifying a lot of tests as well. You're also risking "Copycat syndrome", where the same programmer writes both the unit test and the code that is being tested, and any mental error is therefore likely to exist in both, thus making the test completely useless.
A solution to copycat syndrome is to disentangle the writing of the test with the writing of the code. This is obviously easy to do when one person writes the test and another writes the implementation, but you can do it on your own - just make sure there's time and a 'mental break' between writing tests and writing the implementation, enough to prevent your brain from replaying the exact same reasoning when writing either (which is the likely path to making the same error twice in a row without realizing).
However, when you disentangle like this, it becomes really weird and unwieldy to test with the granularity of 'testing the private stuff' - testing like this tends to follow the notion of 'there is some API spec of sorts and that is what we test', and private stuff by definition isn't part of such a spec.
Whether you like to write the tests first, or the tests last - the same principle applies. It's bizarre to write tests and, during the writing of them, already start cooking up the private methods that you envision will be required to implement it: That's not your 'job' as test writer.
It's similarly strange (slightly less so, perhaps) to write tests that test implementation choices.
SO isn't intended for opinion so I won't spend more than two sentences on it, but my strong suggestion is that third option. private means: Not to be tested directly.
1) Really, any test where the scope of what it tests is clearly restricted to some 'unit' of code that in your project's code style rules requires being in a single package. The two concepts ('what do I stuff in packages' and 'what does this test' need to at least line up, or 'what do I test' needs to be more finegrained than that). In other words, integration tests that test the entire project don't get to use this strategy at all, but then if those are testing private variables, I'm pretty sure you're doing something wrong.

Well, here you have some working code using reflection:
// Assuming you have the objects
ProcessStatusResult processStatusResult = new ProcessStatusResult(new ProcessStatus());
ProcessStatusBody processStatusBody = processStatusResult.getBody();
try {
// The status field, you know the name, right?
Field privateField = ProcessStatusBody.class.getDeclaredField("status");
// Set the accessibility to true since it is not visible
privateField.setAccessible(true);
// Here we go
ProcessStatus status = (ProcessStatus) privateField.get(processStatusBody);
System.out.println(status);
} catch (NoSuchFieldException | SecurityException | IllegalArgumentException | IllegalAccessException e) {
// do something
}
Sorry, I didn't realize you said: "Is there a way to use reflection..."

Unit Testing and White Box Testing

Currently, I'm in a position where I'm to write unit tests for source code I have complete visibility of (which I think means it's considered white box testing?). So, this isn't test-driven development.
Reading this (What is the difference between integration and unit tests?) clarified a lot about what the purpose of all this is, but I'm confused about my current position still.
Let's say I have a method like so:
/* Some basic description on what doSomething() does */
public int doSomething(Var someVariable) {
int someInteger = [code does a bunch of stuff to get this];
someInteger = someOtherClassObject.doSomethingElse(someInteger);
return someInteger;
}
Now, I don't really know what doSomething() is supposed to do. The documentation isn't enough to really tell me what int is supposed to come out based on someVariable, and I'm not familiar enough with the source code to really come up with it myself.
But I do have the implementation, so I look at the method, put in some Var as the input, and follow the code and assert against what it looks like it would return.
public void testDoSomething() {
ClassWithDoSomething object = new ClassWithDoSomething();
assertEquals([what it looks like it would return], object.doSomething(new Var([some input would go here]));
}
Where some way, somehow, I mock out the doSomethingElse() call and the Var constructor (and other external class dependencies if need be).
I don't know whether this is the right way to go about these unit tests. I think I'm isolating the method as I should, but I don't know how meaningful my assert is in determining whether there is a bug or not, because I know just what the method doSomething() is supposed to do in code, and how it's going to go about it, and so I've written my assertion to get that result.
The answer I've read details how unit tests are beneficial due to the method doSomething()'s isolated failure. But when would its unit test ever fail, other than when doSomething()'s implementation changes (which would mean a change in the unit test)?
Is this an issue of not knowing the source code well enough/the source code not being well documented enough to just be able to know what output I should be getting?
If [code does a bunch of stuff to get this] was really just someVariable + 3 where someVariable was an int, is it considered a meaningful assert to assert that the return value is someVariable + 3 when I know the test is going to pass based on that implementation?

But when would its unit test ever fail?
You have it exactly right; the unit test will fail when doSomething's implementation changes. The point of the unit test is to catch it when a seemingly-innocuous change actually breaks the method.
Unit tests often look similar to the code snippet you posted:
public void testDoSomething() {
ClassWithDoSomething object = new ClassWithDoSomething();
object.someOtherClassObject = new MockOtherClass();
assertEquals(4, object.doSomething(new Var("Input that maps to 4"));
}
Both SomeOtherClass and MockOtherClass implement an IOtherClass interface that specifies doSomethingElse. MockOtherClass simply returns the input when you call its doSomethingElse method.

i'd say it's pointless to write unit testing if you don't know what the code is expected to do.
unit testing is checking if given some input code behaves correctly. if you don't know what does 'correctly' mean then how can you test it? you have to understand intention of the code before writing valuable tests.
the situation is a bit different if you write tests in order to rewrite the source code from scratch. in this case tests are the best safety net you can get because they document the actual behaviour and guarantee it won't change. but even in this case, without knowing what the code does, it's easy to miss some corner cases.
so i recommend to always know the intention of the code before you write tests.

Should we check no changes in unit tests?

This example is custom made to ask my doubt.
Object Car {
color:null
tyre : 0;
}
fillCar(Object Car, boolean b) {
if (b) {
Car.color = "Red"
} else {
Car.tyre = 4;
}
}
Now i need to unit test my code.
My test1 is (Car, true) and test2 is (Car, false).
My question:
Do i need to test "tyres == 4" when in test1 and on similar lines do i need to check "color == null" when test2 ?

The answer is YES if this is part of the functional requirement of the method.
For example, if your specifications say that when True the value of tyre must be 4 and other variables will not matter, then it is not necessary. But if your specifications say that not only tyre must be 4 but the rest of variables must remain with the same value, then you should check that out too.
Take into account that Unit test not only are useful for checking that your code is fine, but also for making sure that when your code in the future, you do not corrupt the expected functionality.

Generally, there is no harm in testing all parts of the code. In fact, I would encourage it. It's a very easy way of checking that no mistakes have been made in the logic.
In this case, the code is simple enough to see the result. However, it could become much more complex if Car is extended, or more functionality added.

There is a lot of argument about this but unit testing started to make sense to me once I focused on verifying the interface. In this case you have a function which exposes an interface where you can pass in a car-object and a boolean and then have certain modifications made to the car object depending on the value of the boolean. You quite rightly see two unit tests covering that and personally I would stop there. If you are worried about nulls showing up you can cover that in the unit tests when the car objects are constructed. If you assign something other than a straight forward literal that might be a null then tests for nulls would make sense.
One more tip - unit testing works much better for me within the context of test driven design (TDD). YMMV but I find non-TDD code very hard to unit test.
Finally - just a mention that I found learning TDD/unit-testing is well worth it.

Is it correct to isolate a unit test at method level and stub internal method calls?

I always have the doubt if unit testing isolation should be done at very fine grain like stubbing internal method calls, look at the following example with Java, JUnit and Mockito.
package com.company.domain;
public class Foo {
private FooHelper helper;
public setHelper(FooHelper helper) {
this.helper = helper;
}
public Double method1(Integer a, Integer b) {
... // logic here
Integer var = method2(a); // internal call to method2
... // more logic here
}
protected Integer method2(Integer c) {
... // logic here and return an Integer
}
}
This is the test class:
package com.company.domain;
#RunWith(MockitoJUnitRunner.class)
public class FooTest {
#Mock private FooHelper fooHelperMock; // mocking dependencies as usual
#InjectMocks #Spy Foo foo; // this way we can stub internal calls
#Test
public void method1Test() {
doReturn(2).when(foo).method2(1); //stub the internal method call
... // stub fooHelperMock method calls here
Double result = foo.method1(1, 2);
assertEquals(new Double(1.54), result);
verify(foo, times(1)).method2(1);
... // verify fooHelperMock method calls here
}
#Test
public void method2Test() {
... // stub fooHelper method calls here
assertEquals(new Integer(5), foo.method2(3));
... // verify fooHelperMock method calls here
}
}
I think this way you are able to really isolate the code under testing at method level even with internal calls. But I cannot find lot of information about this being considered a good practice or not and why.

In general, testing a class's internal function calls makes your tests far too fragile. When unit testing, you only want to see that the class as a whole is doing what it is supposed to do. You are supposed to intentionally ignore the internals.
Ignoring the internals has a lot of useful benefits. Mainly, if you change the methods -- as long as the public interface stays the same -- your tests will all still pass. Yay. This is the type of stability you want your unit tests to have. Fragile unit tests are almost worse than no unit tests. A fragile test has to be changed every time the code changes even if everything is still working. That provides you with nothing but extra work.
There are exceptions though. I would consider mocking out internal function calls in the following cases:
1) The internal call pulls data from somewhere. For example a database or large file. This is often called a 'boundary' test. We don't want to really set up a database or file to test, so instead we just sub out the function. However, if you find yourself doing this, it probably means that your class should be split into two classes because it is doing too many different things. Make yourself a dedicated database class instead.
2) The internal call does heavy processing that takes a lot of time. In that case, it might make sense to sub out the function instead of waiting. However, once again this might be a sign that you're on the wrong track. You should try to find a way to make things more partitioned so no single step takes that long.
In conclusion, I would highly recommend you do not test at the method level. A class should be a distinct unit. If the class is working everything is fine. This approach give you the testing you need to be secure and the flexibility you need to change things.
#raspacorp
Indeed, if you only test one case, someone could hardcode var = 2 and then pass your test case. But it is your job in designing tests cases to cover enough different cases to be reasonably satisfied that it is behaving appropriately.
As far as tests changing because the code has changed, this is not what you want at all. You want your tests to verify that the responses you are getting are correct for all the different types of cases. As long as the responses are correct, you want to be able to change everything without changing the tests at all.
Imagine a large system with thousands of tests verifing that everything is working right. Now imagine that you want to make a HUGE optimization change that will make things go faster, but change how everything is stored and calculated. What you want your tests to allow you to do is only change code (not tests) and have the tests continually confirm that everything is still working. This is what unit tests are for, not catching every possible line change, but rather to verify that all the calculations and behaviors are corrent.

This article from Martin Fowler answers your question.
You're a mockist, as I'm, but there are many people who don't like this approach and prefer the classicist approach (e.g. Kent Beck).
Roy Osherove says that the goal of a test, when it fails, is to identify the production code causing the problem, and having that in mind is obvious that the more fine grained the better.
For sure being a mockist may be overwhelming for beginners, but once you're used to the mechanisms of a Mocking library the benefits are uncountable while the effort is not much higher than the other approach.

I do not think it is necessary and I would even go further to say you should not do this. You are writing more test code to test less of you application code. In general it is considered good practice to only test public methods, because a unit test should only be concerned whether a method under test satisfies its contract (i.e. does what it is supposed to do) and not how the method is implemented. If you have a bug in your private method, how will you know?

Under what conditions should I test get() and set() methods?

I could not confirm whether to do these tests. It seems the set and get method is so simple,such as:
setA(String A) {
this.A = A;
}
getA(){
return A;
}
Any ideas would be appreciated!
Thanks,
Joseph

I've only seen a very few problems with getters and setters in the wild, and only one of those could have been detected via a unit test, and only then if all of the getters and setters were tested together, rather than by individual test methods.
Consider the copy/paste mistake of reusing the same field from two different pairs of getters/setters. I.e.,
public void setA(Object a) {
this.a = a;
}
public Object getA() {
return a;
}
public void setB(Object a) {
this.a = a;
}
public Object getB() {
return a;
}
Unit tests that focus on one setter/getter pair at a time won't expose the problem.
Modern IDEs will generate getters and setters on request, so this mistake is unlikely, but not everyone uses modern IDEs. (A vi user created the bug above.) And if these methods reside in a simple data-holder object, the problem may only show up a bit far from the cause.
For this reason, if I test getters and setters at all (and I often don't), it's from a single test method that calls all of the setters first with distinct values, then asserts on all of the getters.
One problem you've got to live with, though, is that there's no guarantee that a method that starts life as a "simple" getter or setter will stay that way when someone else gets their hands on the code and decides, say, that a getter is a good place do something that involves a side-effect.

General rule: Not much point in writing tests for getters and setters. Only if they have some additional logic, ie. are not pure accessors, you should write the tests.

The only time I would write tests specifically for set() and get() methods, is if there is some sort of logic inside them. Eg. limit an integer to between 1 and 8
public void SetA(int a)
{
if(a > 8 || a < 1)
{
throw new IndexOutOfBoundsException();
}
this.a = a;
}
Even though the code above is a very simple example, when you do this type of logic, it can be a good idea to run a test on them. Mainly for when your business rules change and you have to limit it to between 9 and 1 :)

A smart man once said "Test until fear turns to boredom". If you no longer fear that your super-simple code will break, don't write tests unless you're not bored writing those tests. And don't write tests just to "improve your metrics," that's just gaming the system. Write tests to make sure your code works, to improve robustness, and to create confidence that you can refactor freely.

Make a cost/benefit analisis
What would it gain
knowing that the private variable indeed get read/written
What would it cost
the time taken to write the testcase
the time spend, each time executing your testsuite
If you know there are no observable side-effects calling the getter or setter, I wouldn't bother.

Yes, in your case they are trivial - but on the other hand - two simple tests that fully count for quality metrics ;-)
I would create tests. Your application actually relies on the behaviour that the methods really store/access the field values and do not change anything.
Maybe, one day someone decides to change a field type or to add some unit conversion code to a setter/getter - a test will show, if the code still works or it will show, that more work is needed.

They are all same, I say like blank interfaces or business classes. Preprocessing should enable all needed or they are other kinds (doers that both shall return like respond and take 2 variables) language agnostically (even POSIX exit that now is void should use arguments since knowing way is very important)

Writing test cases for methods which can't fail seems disproportionate to me.
Only if the value of A is initialized by configuration or something which could fail
it is worth testing.
EDIT:
Another example when testing makes sense could be a flag 'overdrawn' if an accounts balance becomes negative and you want to check whether the flag was set correctly after calling a method withdraw().

Unit tests are supposed to be the documentation for how the system is supposed to work. Although people often skip unit tests for Properties because the functionality is trivial,
if the tests are the documentation and especially if someone else is going to do the implementation then tests for Properties should be written.
That said, when I am both writing the tests and doing the implementation, I usually skip writing tests for Properties unless they do something more than a simple get/set or if I have spare time, which is a rare thing.