consistent naming for tests

[Nir Lisker]

Sounds good. Maybe also add that junit 5 should be used and 4 is just
legacy.

Note that the wiki also has instructions related to tests, but I think it's
just for running them.

On Wed, Jul 10, 2024, 10:25 Johan Vos <johan.vos at gluonhq.com> wrote:

> Thanks all for commenting.
> What I have read so far seems that there is an agreement for this approach:
> * don't prefix tests with `test` anymore
> * use a (somehow) descriptive name
> * add a comment that refers to the JBS issue that this test is dealing with
> * (optional) in case the test or test scenario is complex, add a comment
> that briefly describes what is being tested.
>
> If that is in line with what most people want, I can create a PR to add
> this to the CONTRIBUTING.md file.
>
> - Johan
>
> On Wed, Jul 10, 2024 at 1:36 AM Nir Lisker <nlisker at gmail.com> wrote:
>
>> * in some cases, tests are always prefixed with `test` (e.g. `testFoo()`)
>>> * in some cases, tests have a concise but somehow meaningful name (e.g.
>>> `testScrollBarStaysVisible`)
>>
>>
>> Prefixing 'test' was an old convention for testing frameworks. I have
>> been dropping that prefix in my projects since I'm in a test
>> class/package/source folder anyway, and it's not like there're methods in a
>> test class that aren't used for testing. I also use long descriptive names,
>> like 'newValueNotSetIfOldValueWasInvalid()' or, alternatively,
>> 'doNotSetNewValueIfOldValueWasInvalid()'. John's nesting names are also
>> good when nesting is appropriate.
>>
>> * in some cases, tests refer to JBS issues (e.g. testJDK8309935)
>>
>> * in some cases, the test is explained in comments.
>>
>>
>> I don't like JBS numbers as names, but I like them as links in a comment.
>> I prefer the name of the test and methods to be self-explanatory, like in
>> non-test code, rather than comments. However, sometimes comments are needed
>> because of tricky or non-trivial situations, which is part of what tests
>> are for.
>>
>>
>> On Tue, Jul 9, 2024 at 6:30 PM Kevin Rushforth <
>> kevin.rushforth at oracle.com> wrote:
>>
>>> This might be a combination of Eclipse and eCryptfs. I agree that 143
>>> chars is very short for a max length.
>>>
>>> -- Kevin
>>>
>>>
>>> On 7/9/2024 8:22 AM, John Hendrikx wrote:
>>>
>>>
>>> On 09/07/2024 16:52, Andy Goryachev wrote:
>>>
>>>
>>>
>>> Two test files consistently generate an error in Eclipse
>>>
>>> - ObservableValueFluentBindingsTest
>>> - LazyObjectBindingTest
>>>
>>>
>>>
>>> I admit I have a weird setup (EncFS on Linux Mint running on MacBook
>>> Pro), and it only manifests itself in Eclipse and not in the gradle build -
>>> perhaps Eclipse actually verifies the removal of files?
>>>
>>>
>>>
>>> Anyway, a suggestion - if you use @Nested, please keep the class names
>>> *short*.
>>>
>>> This is not an Eclipse bug as I never encounter such issues.  143
>>> characters is rather short these days, but I suppose we could limit the
>>> nesting a bit.  Still, I'd look into a way to alleviate this problem in
>>> your setup, sooner or later this is going to be a problem.
>>>
>>> --John
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240710/247eae44/attachment-0001.htm>