Java – unit testing, static and factory

I'm implementing a model in Java. It needs to iterate a set and go through some identification stages. It involves loops, loops, etc This is the kind of thing I want to test at the fine - grained level, so I am confident that it has been properly implemented

I use it as an opportunity to start unit testing because I think it's good for my code Since then, I have been reading a book to quickly master JUnit and unit testing

Basically, my question boils down to two conflicting suggestions I received:

1) Statics is evil Do not touch static electricity Don't test private, you might want a class 2) Create using factories to allow dependency injection using parameters - may allow isolation using impersonation and stubs

In my example, I want to do the following:

double height = 223.42; // this was set iterating over a collection of doubles
//blah
HeightBounds b = HeightBounds.getHeightBounds(height);
//more blah

I do this to avoid building a very long and complex block of code that I can only test thoroughly In this way, I can test public accessible objects to ensure that all system components execute correctly

Common sense tells me that static factories have no problems and they are easy to test, but did I miss something dazzling when I learned test driven design?

thank you

Solution

Static factory classes introduce coupling between classes and highbounds classes If, for example, highbounds closes and looks for information in the DB, or reads information from web services, etc., this may make your class difficult to test

If you inject the iheightbounds implementation into your class, you can simulate it so that you can test what happens when your class's dependencies perform certain operations

For example, what if highbounds throws an exception? Or return null? Or do you want to test when to return a specific highbound? This behavior can be easily simulated using interfaces. When using static factories, it is more difficult to make data to create the desired results in classes

You can still have only one implementation of highbounds and test it separately, but you can test the above method without a real implementation

I might have an iheightboundfactory interface and inject an implementation into the class

As for personal testing, usually you don't want to You want to test one of two things, either the results meet your expectations or the interaction meets your expectations

If you have a method named Add and a method named GetAll, you may want to test it when calling Add, then call GetAll, and you will get the one you added. You don't care how it works, it just works Here are the test results Usually in this case, you want to create a mock object that returns data This seems to be your case

If you want to record what is being added when you call add, you want to test the interaction with the logging dependency, so you will inject the simulation dependency and verify whether the interaction with this class occurred when you call add Usually in this case, you want to create a mock object with the desired settings and verify that these expectations have been met In the case described above, it does not seem necessary