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

[SUREFIRE-1962] Unit test for ProviderInfo#isApplicable #445

Merged
merged 1 commit into from
Jan 3, 2023

Conversation

slawekjaranowski
Copy link
Member

Following this checklist to help us incorporate your
contribution quickly and easily:

  • Make sure there is a JIRA issue filed
    for the change (usually before you start working on it). Trivial changes like typos do not
    require a JIRA issue. Your pull request should address just this issue, without
    pulling in other changes.
  • Each commit in the pull request should have a meaningful subject line and body.
  • Format the pull request title like [SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles,
    where you replace SUREFIRE-XXX with the appropriate JIRA issue. Best practice
    is to use the JIRA issue title in the pull request title and in the first line of the
    commit message.
  • Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
  • Run mvn clean install to make sure basic checks pass. A more thorough check will
    be performed on your pull request automatically.
  • You have run the integration tests successfully (mvn -Prun-its clean install).

If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.

To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

@Tibor17
Copy link
Contributor

Tibor17 commented Jan 25, 2022

The call new TestNgProviderInfo( null ).isApplicable() returns false.
We call new DynamicProviderInfo( null ).isApplicable() but it returns true.
The impl in DynamicProviderInfo should be a bit more similar to other impl of ProviderInfo and it should not only return the same value without the null check at least.

@Tibor17
Copy link
Contributor

Tibor17 commented Jan 25, 2022

If you read the name of method like a news autoDetectOneWellKnownProvider() it says that one should be detected.
We use to return List<ProviderInfo>. I know why it is. It simplifies the caller but it is not alright. If we have returned Optional<ProviderInfo> the method would be called easily .map(singletonList()).orElse(emptyList()) with Java 8.

@slawekjaranowski
Copy link
Member Author

changes for DynamicProviderInfo implementation should be done in separate PR with new issue.

also changing for autoDetectOneWellKnownProvider method is out of scope for this PR.

@Tibor17
Copy link
Contributor

Tibor17 commented Jan 25, 2022

@slawekjaranowski
Your tests have discovered these cosmetic issues, so yes, pls open new tickets.

@slawekjaranowski
Copy link
Member Author

issues created and linked

public void jUnitPlatformProviderApplicable()
{
Artifact junitPlatform = mock( Artifact.class );
ProviderInfo providerInfo = mojo.new JUnitPlatformProviderInfo( junitPlatform, aTestClassPath() );
Copy link
Contributor

Choose a reason for hiding this comment

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

It would be great to have unit tests for JUnitPlatformProviderInfo because the method getProviderClasspath() is not covered by unit tests, only covered by ITs. The documentation describes the behavior and the provider classpath is always resolved to necessary libraries including API and junit5 impl libraries.

Copy link
Member Author

Choose a reason for hiding this comment

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

it should be done is separate PR - many cases for ``getProviderClasspath`

Copy link
Member Author

Choose a reason for hiding this comment

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

ProviderInfo providerInfo = mojo.new JUnit4ProviderInfo( junit, junitDep );

// ??? only existing for junitDep in any version is checked
assertThat( providerInfo.isApplicable() ).isTrue();
Copy link
Contributor

Choose a reason for hiding this comment

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

It looks like the caller's logic guarantees that the artifact coordinates are junit:junit-dep and JUnit4ProviderInfo makes only the null check. hm...

Copy link
Member Author

Choose a reason for hiding this comment

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

current state - it is done in this way

Copy link
Contributor

Choose a reason for hiding this comment

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

The point of writing the tests is that my eyes stay blind, I should not see the implementation...

Copy link
Member Author

Choose a reason for hiding this comment

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

code assume that input artifacts is correct .. for me looks like mixed responsibility
ProviderInfo should take as input whole classpath of project and take decision on it in one place.

Now we search artifacts in separate methods in AbstractSurefireMojo and pass only result to ProviderInfo ...
in AbstractSurefireMojo should not be any separate logic for it.

But it is another case and place to improvement.

{
Artifact junit = aArtifact( "4.5" );
ProviderInfo providerInfo = mojo.new JUnit4ProviderInfo( junit, null );
assertThat( providerInfo.isApplicable() ).isTrue();
Copy link
Contributor

Choose a reason for hiding this comment

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

If the version is checked, why the groupdId and artifactId is not checked? The caller is checking it?

Copy link
Member Author

Choose a reason for hiding this comment

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

current state ...
test for only JUnit4ProviderInfo not caller

Copy link
Contributor

@Tibor17 Tibor17 Jan 27, 2022

Choose a reason for hiding this comment

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

I am talking about different things:
Why only version is checked? Why the groupId and artifactId are not checked in the impl?
Your artifact is test:test:4.5 in this test. A whatever artifact coordinates *:*:4.5 would pass this test. Do you know what I mean?

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't know why only version is checked, probably is assumptions that input is correct ... artifact is provided by method getJunitArtifact which search specific groupId and artifactId

Copy link
Contributor

Choose a reason for hiding this comment

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

The purpose of writing the uni tests is hiding your eyes and you should write the tests without knowing the implementation, even before the impl exists. Here the impl exists, therefore we should hide our eyes. Then new issues would rise up.

{
Artifact junit = aArtifact( "4.7" );
ProviderInfo providerInfo = mojo.new JUnit4ProviderInfo( junit, null );
// ??? it is ok for 4.7 ???
Copy link
Contributor

Choose a reason for hiding this comment

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

This is ok, it is suitable provider info also for the 4.7+ if you did not configure parallel/groups.
But I see that you have missed the JUnitCoreProviderInfo - it is for 4.7+ and parallel/groups.

Copy link
Member Author

Choose a reason for hiding this comment

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

There is separate test for it AbstractSurefireMojoJunitCoreProvidersInfoTest

@slawekjaranowski
Copy link
Member Author

@Tibor17 Do we want to merge it? I need rebase it.

@slawekjaranowski
Copy link
Member Author

@Tibor17 - ping

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants