Stay cool, have a Mockito.

You are not the first developer in this situation, so someone has automated the creation of 'fake' objects or mocks for us:
Mockito is a framework that can create various objects that are useful for testing.

Mock is an object that behave like a (alternate) implementation of a class or interface. This is akin to an actor (or actress) or stunt-double that behaves exactly like you tell it to. A mock also saves any method call that you do on it.
Stub just holds data that you provide and are presented to the SUT.
Both mock and stub are stand-ins for dependent on components (DOC) or collaborators for the SUT.
There is also a Spy which is in fact a wrapper around an actual implementation, that allows you to observe what goes in (method call+ parameters) and comes out of (return values) of the real object while it is used by the SUT. You can make the spy only spy on certain method calls, and leave the rest unchanged.

Lets see what this looks like in code.

public interface Printer {

    void println( String print );

    /**
     * Make it deal with objects too.
     * @param o to print.
     */
    default void println( Object o ) {
        printLn( o.toString() );
    }
}

Now over to the test class, which creates a mocked printer and hands it to the Business class.

    @Test
    public void doesItPrint() {
        Printer pr = mock( Printer.class );  1

        Business b = new Business( pr );     2

        b.work();                                 3

        verify( pr ).println( anyString() ); 4

    }

This is of course a simple test and the only thing that it verifies is that the printer.printLn(String) has been used.

@Mock
Printer printer; 1

Business business;

@BeforeEach
void setup() {
    business = new Business( printer );  2
}

@Test
void doesItPrintBusiness() {
    var lineCaptor = ArgumentCaptor.forClass( String.class ); 3

    business.work( "Linda" ); 4

    verify( printer ).println( lineCaptor.capture() ); 5
    assertThat( lineCaptor.getAllValues() ).contains( "Hello Linda" ); 6
    //  fail("test does It print ended. You know what to do.");
}

Mockito is well documented with lots of examples in its java doc. When you look to the test dependencies of your Maven project in NetBeans-IDE, right-click on the mockito dependency, then download the javadoc, you can enjoy that while you are developing.

To Mock or To Configure

Sometimes the class that you want to pass as a mock to the business code has a big interface, with many methods, and you do not want to restrict the business code to just a few trained methods. That would constrain the methods that the business class could use, which serves no real purpose. In such cases it may be better to provide a differently configured real class.

class PrintingBusiness
      final PrintStream out; 1

      PrintingBusiness() { 2
          this( System.out );
      }

      PrintingBusiness( PrintStream ps ) { 3
          this.out=ps;
      }

      void businessMethod(){
          out.format( "%s at %d", "Oplegkaas", 957 ); 4
      }
}

    @Test
    public void tformattedPrint() {
        ConsoleOutput cout = new ConsoleOutput();
        PrintStream out = cout.asPrintStream();

        out.format( "%s at %d", "Oplegkaas", 957 );

        assertThat( cout.toString() ).contains( "at", "Oplegkaas", "957" );
    }

@FunctionalInterface
public interface AppendAndClear {

    /**
     * Append a string to this AppendAndClear.
     *
     * @param toAppend text to add.
     */
    void appendText( String toAppend );

    /**
     * Clear the output. Optional operation.
     */
    default void clear() {
    }
}

package consoleoutput;

import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.OutputStream;
import java.io.PrintStream;
import java.nio.charset.Charset;
import java.nio.charset.StandardCharsets;

/**
 * Test helper, to be able to redirect a PrintStream to any writable.
 *
 * Use case: write to string or StringBuilder for test or e.g. javafx
 * TextInputControl for UI. Implement AppendAndClear (which can be done as a
 * lambda) and you're set.
 *
 * @author Pieter van den Hombergh {@code <p.vandenhombergh@fontys.nl>}
 */
public class ConsoleOutput extends OutputStream {

    protected final ByteArrayOutputStream baos = new ByteArrayOutputStream();
    final AppendAndClear aac;

    /**
     * Create a Console output copying data to given AppendAndClear.
     *
     * @param ta append and clear to copy all written text to.
     */
    public ConsoleOutput( AppendAndClear ta ) {
        this.aac = ta;
    }

    /**
     * Without appendable.
     */
    public ConsoleOutput() {
        this( null );
    }

    @Override
    public void write( int b ) throws IOException {
        if ( aac != null ) {
            String s = "" + ( (char) b );
            aac.appendText( s );
        }
        baos.write( (byte) b );
    }

    /**
     * Clear and discard output.
     */
    public void clear() {
        if ( aac != null ) {
            aac.clear();
        }
        baos.reset();
    }

    /**
     * Get the accumulated string since start or clear.
     *
     * @return the string
     */
    @Override
    public String toString() {
        return new String( baos.toByteArray(), StandardCharsets.UTF_8 );
    }

    /**
     * Factory method to get this ConsoleOutput as PrintStream.
     *
     * @return the print stream.
     */
    public PrintStream asPrintStream() {
        return new PrintStream( this, true, Charset.defaultCharset() );
    }
} // eof ConsoleOutput

Business class fit for testing

WE’LL FURTHER EXPLAIN THIS CONCEPT IN CLASS AND IN THE CONTEXT OF PRJ2. THERE ARE QUITE SOME DESIGN IDEAS BEHIND IT, SO DON’T WORRY IF YOU DON’T UNDERSTAND IT IMMEDIATELY.

Let us look at an example as a class diagram.

In the picture above you see a class diagram which shows a detail in which a business class 'lives' in an environment that is designed to make sure the business class sticks to its business:

Dealing with business entities such as customers and products.
Uses services to do the business' bidding, such as saving stuff to a database, provided as a service to the business class.
And the business code NOT responsible for how to show things in a UI.

In the above example we provide a factory or provider of the services that the business code requires.

The business class appears in two worlds:

Before the business class can used in real life, it has to be trained and tested. Feels a bit like a student right?

You should note the arrows in the diagram. They provide direction and make it the diagram a directed graph, and lets a dependent point to a depends-on, like the BusinessClass depends on a Service, which is an abstract class or better still, an interface. Also note that the service does not point to, or is dependent on the business, which is good, because it makes the service reusable in other contexts.
The service implementing classes are dependent on the Service definition which is shown with the "implements arrow", pointing from sub to super type.

In the business school, there is a test class, that creates instances of the business class and hands it implementations of the services the business needs, but does that by giving it a specialized service factory that produces mock service implementations. The business class is NOT aware of that. It uses the service in the way it is programmed, which allows the test class to verify that that programming is correct. The test class is in complete control and can also give the business class situations that are extensions to the normal happy path to ensure that those situations are also handled properly. If that sounds like an exam setting at school, you would be right.

You can tell these worlds in the class diagrams apart by the fact that one has a pink BusinessTest class with test methods.

In the 'normal' non-testing Application world, the design has taken some provisions to make sure the business class can work in both worlds. To provide the business class with a factory from which it can obtain Service implementations, a so called Assembler is added. This Assembler, in the figure at the top of the application class diagram, typically creates or instantiates the business class and provides it with all it needs, in this case an implementation of a ServiceFactory. Note that the assembler in this case also creates the UI part. In desktop applications this is the responsibility of the Main class of the application.

This approach of providing an instance of some class implementing an interface or realizing an abstract class to a business class that needs it is called dependency injection.

Dependency injection is providing the services required by some class by means of constructor parameters, setters or otherwise, to avoid that the dependencies of the class are created by that class itself.