Add simple Unit tests

[koppor]

JabRef offers unit testing based on JUnit5. There are still untested functionalities and not good tests. Here are some tasks in that field.

Please first read our writings on testing.

• DO NOT ADD GUI TESTS AS THESE ARE NOT SIMPLE AT ALL
• Create one pull request for one test class; this makes reviewing easier. If you change MinifyNameListFormatterTest, DOICheckTest, ... in one pull request, reviewing is hard, because they are all unrelated classes.

Unit test creation

Creating unit tests can be trained creating tests for classes residing in following packages

• org.jabref.logic.integrity

(to be continued)

There is no need to test all classes. Just pick one or two. Testing takes time and one carefully needs to think about the intention of the class to be able to check user-centric good cases and bad case.

Please also think of adding documentation to https://github.com/JabRef/user-documentation after you understood the intension of the class.

Unit tests improvement

• split multiple asserts into different test cases.
  It is an antipattern having multiple assert statements in a test case. Thus, they should be split - with meantingful test names

  Example:

     @Test
     void testNoteChecks() {
         assertCorrect(withMode(createContext(StandardField.NOTE, "Lorem ipsum"), BibDatabaseMode.BIBTEX));
         assertCorrect(withMode(createContext(StandardField.NOTE, "Lorem ipsum? 10"), BibDatabaseMode.BIBTEX));
         assertWrong(withMode(createContext(StandardField.NOTE, "lorem ipsum"), BibDatabaseMode.BIBTEX));
         assertCorrect(withMode(createContext(StandardField.NOTE, "Lorem ipsum"), BibDatabaseMode.BIBLATEX));
         assertCorrect(withMode(createContext(StandardField.NOTE, "\\url{someurl}"), BibDatabaseMode.BIBTEX));
         assertCorrect(withMode(createContext(StandardField.NOTE, "lorem ipsum"), BibDatabaseMode.BIBLATEX));
     }

• Add paramaterized tests

• org.jabref.logic.integrity.IntegrityCheckTest: split tests into tests for each integrity check class (e.g. checking editions should go to EditionChecker)

(to be continued)

Other tests to work on

• Add more file test cases jabref-koppor#484
• Include test cases for other types jabref-koppor#29

[dimitra-karadima]

I'd like to work on that!

[koppor]

@dimitra-karadima Sure! Just go ahead. Please open a work-in-progress pull request after your first additions. I have no stron oppinion on which classes need testing and which test classes need restructuring. Just work on it as long as you feel comfortable.

[robert-do]

Hello koppor
Lars and I have chosen the project which is related to this task. We wanted to ask you whether you can recommend us some specific functions which we could write a test for as part of the project which will benefit you the most.
Kind regards,
Robert

[koppor]

Dear Lars and Robert,

We aim for 100% code coverage. You can check existing coverage with IntellIJ or Eclipse. You should see which classes have not that many test

Update Do not force the 100% coverage; think of good tests. For instance, test hard things such as unlinked files (see JabRef#484 ) instead of tostring. See also https://ondrej-kvasnovsky.medium.com/is-100-test-coverage-worth-it-2e086ca4d41c and https://blog.ndepend.com/aim-100-percent-test-coverage/

I would love to see automated tests for features described in the user documentation. However, this is much work.

I assume you checked the integrity package (mentioned in the issue description) for current test coverage?

Cheers,

Oliver

[nasdas-dev]

Hi Oliver

We are a group of four MSc students from the University of Zurich, @ningxie1991, @BShaq, @Davfon, and myself @nasdas-dev.
As part of a software testing course we are enrolled in, we would like to contribute to this project over the next few weeks and increase the total code coverage as much as we can.

We created a new fork (ningxie1991/jabref) and work on our individual branches there. We will then create a pull request after each segment of work we have completed and reference this issue ticket.

Let us know if that works for you!
Best Regards
Dario

[Siedlerchr]

For anyone else wanting to contribute some Unit Tests. The TemplateExporter currently have not yet any unit tests, that would also be a great improvement

[koppor]

Testing should aim for discovering bugs and ease maintenance of code. Thus, test real functionality. Do not test simple getters or toString methods! Tests should focus on ensuring that code change keep desired customer functionality.

[tobiasdiez]

Given the amazing progress over the last few days (especially once all of the above PRs are merged), should we close this issue and return to our "only refactor if you work on this part of the code anyway" policy?

(Then I would also suggest to copy most of the issue text to the contribution guide / how to write tests).