4

I'm working on an application that has a custom look and feel. For GUI testing, I am using FEST-Swing. Currently, the GUI tests are running with the default java look and feel. Because of this, some tests are failing, but should I consider this to be a bug in the GUI, or test using my custom look and feel?

Later edit:

Thank you Andrew Tompson for the quick answer. But the issue I think still remains, because of the way the flow layout works. Here's a mockup of what happens:

enter image description here

The standard LAF uses a bigger font than the one I am using, and this causes one of the buttons to get out of the layout. And I can't use pack(), since there's a size requirement for that container. If you didn't call frame.pack() in that example, I think you would have the same issue.

mKorbel
  • 109,525
  • 20
  • 134
  • 319
Radu Pluta
  • 131
  • 4

2 Answers2

5

some buttons are too big and don't get rendered in the window .. should I consider this to be a bug in the GUI ..

Yes. It seems as though the current GUI is very fragile. See the Nested Layout Example for a GUI that works in any PLAF.

Community
  • 1
  • 1
Andrew Thompson
  • 168,117
  • 40
  • 217
  • 433
  • So I should keep the tests running with the default look and feel and change the layout. Thank you! – Radu Pluta May 14 '13 at 09:42
  • 2
    @negurici this si quite good described in official Oracle tutorial, JFrame.pack() is required in all cases when L&F changed, you are out of luck in the case that JFrames size is hardcoded ... – mKorbel May 14 '13 at 10:18
  • 1
    *"But the issue I think still remains"* The same issue that I already suggested a solution for. *"I can't use pack(), since there's a size requirement for that container"* Yes. The right size to contain the components (with appropriate margins & borders). That size is supplied by `pack()`. What, are you going to suggest that 'the boss' told you how many pixels wide and tall that box should be? If so, the boss is a moron & the product will always be fragile. Nothing more I can do about it. – Andrew Thompson May 14 '13 at 10:27
  • agreed with fragile, sure there is another choice, override all used LayoutManager (could be crazy as is possible) that accepting hardcoded sizing, notice use internally sizing came from SwingUtilities.calculateInnerArea / layoutCompoundLabel / computeStringWidth – mKorbel May 14 '13 at 11:00
  • Thank you for the responses. Unfortunately there's not a lot I can do, but hopefully the answers will help some other guys with similar problems. – Radu Pluta May 14 '13 at 12:30
  • 1
    This answer is correct; re update, don't do [this](http://stackoverflow.com/a/12532237/230513), either. – trashgod May 14 '13 at 16:02
1

You should test using your custom look and feel! It's not a bug in the GUI per se.

The standard LAF uses a bigger font than the one I am using, and this causes one of the buttons to get out of the layout. And I can't use pack(), since there's a size requirement for that container. If you didn't call frame.pack() in that example, I think you would have the same issue.

You have a size requirement for the container. This means that with standard LAF no LayoutManager could compute any arrangement of the components in the container, so that they all would fit in standard LAF because as you point out they're just too big. It means you cannot have standard LAF and the size requirement.

As long as you use only your custom LAF and test with this custom LAF on all supported OS systems and no test fails everything is alright. So just change your tests and switch to your custom LAF before executing the tests.

In case you ever want to run your application in standard LAF you'll have to relax the size requirement until everything is displayed properly using a capable LayoutManager. For example with MigLayout you can conveniently set all these size requirements and still use pack() on the JFrame in the end.

edit: I agree with Andrew that you should critically review the need for the size requirement. In many cases these requirements aren't really required and dropping them reduces the 'failures' in layouting greatly. For example you might just specify a minimum size for the container.

NoDataDumpNoContribution
  • 10,591
  • 9
  • 64
  • 104