Hello, Dmitriy. Looks much better now. Less code, ore understandable) Just a couple of minor comments left and we are good to go)
SetBounds: 90: you don't need to catch the exception, let it propagate also. The test would fail anyway if you could not create a robot. 155: Please have a look on the asserts sources. It doesn't print the message as is, but adds smth like "expected: true but was: false" So you'd better write messages like "Button triggered action when clicked". So just describe the action you are asserting. LockingKeyStateTest 56: Method reference would look nice here) Just a suggestion.. 103: some weird commented out code left Thank you. With best regards. Petr. On 10.04.2014, at 15:17, Yuri Nesterenko <[email protected]> wrote: > Not that I have something against this fix but > I feel it may be not necessary in future to use > SwingUtilities in all-AWT tests. > > -yan > > On 04/10/2014 03:03 PM, Dmitriy Ermashov wrote: >> Hi, >> Please, review the changeset for: >> https://bugs.openjdk.java.net/browse/JDK-8039279 >> >> Webrev is here: >> http://cr.openjdk.java.net/~yan/8039279/webrev.01/ >> >> Changelist: >> 1. Got rid of using applet in SetBounds test >> 2. Tests switched on using pattern "throw RuntimeException on fail" >> 3. ModifierRobotKeyTest now uses SwingUtilities, OSInfo and FocusAdapter >> classes >> 4. Using jdk.testlibrary.Asserts methods from lib/testlibrary folder >> >> Test runs on the following platforms seems stable: >> Windows 7 x64, Intel graphical card >> Ubuntu Linux 12.04 x64, Intel graphical card >> OS X 10.8.5 x64, NVIDIA GeForce 9400 >> Ubuntu 10.04 ARMv7 >> >
