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....@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 <nlis...@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.rushfo...@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 >>> >>> >>>
