assertj / assertj-swing

Fluent assertions for Swing apps
Other
108 stars 52 forks source link

Using AssertJ with java.applet/java.awt Components #249

Closed kidomine closed 4 years ago

kidomine commented 4 years ago

Hi, I'm working on a legacy application which uses only java.applet.Applet and java.awt components for its UI (e.g. Button instead of JButton, etc.).

Following AssertJ documentation, I was able to create a FrameFixture by doing something similar to the following:

public class MyApplet extends Applet {
    ::
}

public class MyAppletTest {
    private AppletViewer appletViewer;
    private FrameFixture frameFixture;

    @Before
    public void setUp() {
        appletViewer = AppletLauncher.applet(MyApplet.class).start();
        frameFixture = new FrameFixture(viewer);
        frameFixture.show();
    }
}

The problem starts when I try to test the behavior of components. More specifically, I was trying to manipulate a Button component as follows:

    @Test
    public void onCreate_ShowsButtonWithCorrectLabel()
    {
        frameFixture.button("myButton").requireText("click me");
    }

The test fails because AssertJ cannot find the Button. However, when I use JButton instead of Button, AssertJ can find it without issue, and I can manipulate the component as expected.

In order to get around it, I had to do something like the following:

    // in setUp:
    // finder = BasicComponentFinder.finderWithNewAwtHierarchy();

    @Test
    public void onCreate_ShowsButtonWithCorrectLabel()
    {
        Button button  = (Button)finder.findByName(appletViewer.getApplet(), "myButton", true);
        assertNotNull(button);
        assertEquals("click me", button.getLabel());
    }

Then, to click the Button I had to do something like:

    ::
    Button button  = (Button)finder.findByName(appletViewer.getApplet(), "myButton", true);
    frameFixture.robot().click(button);
    ::

instead of:

    ::
    frameFixture.button("myButton").click();
    ::

My question: is there a better way of dealing with non-Swing components other than what I am doing? The use of basic Applet and AWT components are pretty much a constraint I have no control over.

croesch commented 4 years ago

Hi @kidomine

Thanks for this question - but before I answer anything, please understand that AWT components and Applet testing is nearly the outer edge of the term legacy ;-) and thus I'm not able to produce a running or even compiling example.

Sorry for answering that late .. are you still working on that?

But I can give you some hints and hopefully be able to point you in the right direction..

Yes, testing AWT components is not nice with AssertJ-Swing (out of the box).

But - luckily - yes, there is a better way of dealing with non-Swing components:

You can start digging around at https://github.com/joel-costigliola/assertj-swing/blob/master/assertj-swing/src/main/java/org/assertj/swing/fixture/AbstractContainerFixture.java#L142 to get a basic understanding of AssertJ-Swing's API: basically you a working with a JButtonFixture - but want something like a ButtonFixture.

Have a look at https://joel-costigliola.github.io/assertj/assertj-swing-advanced.html - more specific at Extending AssertJ Swing. It covers pretty much exactly your usecase: Implement your own ButtonFixture and if you followed the rest of the guide, you can access it via:

frame.with(buttonWithName("myButton")).click();

You can also have a look at https://github.com/joel-costigliola/assertj-swing/blob/master/assertj-swing-jide/src/main/java/org/assertj/swing/jide/JideFrameFixture.java how for example https://github.com/joel-costigliola/assertj-swing/blob/master/assertj-swing-jide/src/main/java/org/assertj/swing/jide/grids/JideTableFixture.java is made testable.

So yes, there is a better way which requires just a little bit of coding and should improve the coding style of your tests dramatically.

I'm closing the issue, because I feel like the question is answered. However late. If you have a question to the answer, just reopen the issue :-)

kidomine commented 4 years ago

Hi @croesch

Thanks for the detailed response.

Unfortunately(?) our team decided it is not worth the effort to perform UI testing for our legacy application, so its no longer a big deal. However, I suspect that in the future I will encounter the same or similar issue considering that our environment is old and any new application will most likely be using non-Swing components.

In any case, I will check the links that you provided, and hopefully I can work out something.