Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add more unit tests #7638

Merged
merged 7 commits into from
May 21, 2021
Merged

Add more unit tests #7638

merged 7 commits into from
May 21, 2021

Conversation

Davfon
Copy link
Contributor

@Davfon Davfon commented Apr 17, 2021

This pull request contributes to issue #6207, which is to add more unit tests to the project. The tests make use of mocks (stubbing) to simulate the behavior of some classes.

Tests added:

ImporterViewModelTest
BibStringDiffTest
PreambleDiffTest

  • Change in CHANGELOG.md described in a way that is understandable for the average user (if applicable)
  • Tests created for changes (if applicable)
  • Manually tested changed features in running JabRef (always required)
  • Screenshots added in PR description (for UI changes)
  • Checked documentation: Is the information available and up to date? If not created an issue at https://github.com/JabRef/user-documentation/issues or, even better, submitted a pull request to the documentation repository.


public class ImporterViewModelTest {

private final CustomImporter importer = mock(CustomImporter.class);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This whole test does not test any functionality. You are just testing java's getter and setter or property.
Don't just write tests for the sake of increasing testscoverage. Testing should concencrate on testing logic or implementaition

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can of course exclude this test, if you prefer so. I understand that testing logic and implementation is more valueable than increasing coverage. But higher coverage ultimately reaches the same goal. And according to the comment on issue #6207 the aim is to reach 100% code coverage.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed the text, because the knowledge that increasing coverage in an equal way is not as common as I assumed. I mean: If one class has 10% coverage, another has 90%, it is better to work on the class having 10% than trying to increase the coverage from 90% to 100% in the 90% class.

@koppor koppor added the status: changes required Pull requests that are not yet complete label May 6, 2021
@Siedlerchr
Copy link
Member

It would be really nice if you would finish this PR asap! @Davfon

@Davfon
Copy link
Contributor Author

Davfon commented May 11, 2021

It would be really nice if you would finish this PR asap! @Davfon

Thanks for the feedback and sorry for the late response. I will try to do the changes by tomorrow evening.

@Davfon
Copy link
Contributor Author

Davfon commented May 12, 2021

Should be all good now. Had to override the equals method. (And add hashCode() for checkstyle) Thanks again for the good inputs.

@@ -88,4 +88,18 @@ public BibtexString getOriginalString() {
public BibtexString getNewString() {
return newString;
}

@Override
public boolean equals(Object other) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
public boolean equals(Object other) {
public boolean equals(Object other) {
if (this == other) {
return true;
}
if ((other == null) || (getClass() != other.getClass())) {
return false;
}
BibStringDiff that = (BibStringDiff) other;
return Objects.equals(newString, other.newString) && Objects.equals(originalString, that.originalString);

Do not use toString() beause the BIbTexString class has it's own equals methods which will then be called autoamtically internally.

And tip for the next time: Your IDE has an option to generate equals/hasCode methos

Copy link
Contributor Author

@Davfon Davfon May 13, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point, but since the BibtexString equals() method is strict and also compares the IDs of two BibtexStrings, it makes things a bit more complicated.

Is it intended, that two BibtexStrings that only differ in their ID are not considered equal? Because right now these would not be equal:

    private final BibtexString bStr1 = new BibtexString("name", "content");
    private final BibtexString bStr2 = new BibtexString("name", "content");

Since they get different IDs when they are created.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@koppor you have more knowledge of this BibtexStrings, can I have multiple ones with the same name?

@Davfon you might check the BibtexString dialog for some clues if there are additional restrictions

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Strings are IMHO key/value pairs: https://docs.jabref.org/fields/strings.

I think, the Id fiels should not be treated when "equals". However, please, please have a look at the way how a BibEntry is compared and how Ids are treated. There should be a comment on that in the JavaDoc.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think so too (that they are key/value pairs)

A BibEntry is compared by type, fields & commentsBeforeEntry. The Ids are not used for comparing. There was no JavaDoc for the equals method. I would suggest removing the Id comparison in the BibtexString.equals() method. (see last commit)

Copy link
Member

@koppor koppor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some comments on tests

@Siedlerchr Siedlerchr merged commit 7196eb3 into JabRef:main May 21, 2021
@Siedlerchr
Copy link
Member

Thanks for the follow up fixes and as you can see you discovered an error in the equals implementation for the BibTexStrings

Siedlerchr added a commit that referenced this pull request May 21, 2021
* upstream/main:
  Add more unit tests (#7638)
  Fix for issue 5804: Rewrite ACM fetcher (#7733)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: changes required Pull requests that are not yet complete
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants