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

Allow static imports of AssertJ and Mockito #852

Closed
wants to merge 2 commits into from
Closed

Allow static imports of AssertJ and Mockito #852

wants to merge 2 commits into from

Conversation

pkoenig10
Copy link
Member

Before this PR

It's common to have a test utility project which is a test dependency in other projects. We currently allow static imports in tests (#240) but that does not apply to test utility projects since they are main sources.

This paper cut is aggravated by the PreferAssertJ check (#841) which static imports AssertJ methods. Doing this causes automated baseline upgrades to require manual intervention to successfully compile.

After this PR

We allow static imports of AssertJ and Mockito methods.

@pkoenig10 pkoenig10 requested a review from a team as a code owner September 18, 2019 20:42
@changelog-app
Copy link

changelog-app bot commented Sep 18, 2019

Generate changelog in changelog/@unreleased

Type

  • Feature
  • Improvement
  • Fix
  • Break
  • Deprecation
  • Manual task
  • Migration

Description

Baseline now allows static imports of AssertJ and Mockito methods.

Check the box to generate changelog(s)

  • Generate changelog entry

@ferozco
Copy link
Contributor

ferozco commented Sep 18, 2019

Given that the preferAsserJ migration is a onetime cost, I'm not sure if its worth widening the set of allowed static imports

@pkoenig10
Copy link
Member Author

This isn't just for the AssertJ migration. It's cumbersome to not be able to use static imports in test utility classes just because they are part of the main source set in a test utility project.

These classes aren't going to be imported in non-test code so what's the downside of allowing them to be statically imported? These classes are almost universally statically imported in test code currently.

@carterkozak
Copy link
Contributor

@schlosna
Copy link
Contributor

@pkoenig10 can you use Gradle 5.6+ test fixtures?

@pkoenig10
Copy link
Member Author

@carterkozak this is utility class used in tests, but it is not in a test source set. It is in a separate project that is imported as a test dependency in multiple other projects.

@schlosna test fixtures sound like exactly what I'm looking for, thanks for pointing that out!

I still think there is value in allowing these classes to be statically imported. Not everyone is going to have the ability or resources to migrate to test fixtures and the downside of allowing these classes to be imported is low.

Copy link
Contributor

@iamdanfox iamdanfox left a comment

Choose a reason for hiding this comment

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

I just found an excavator assertj PR which was blocked by this checkstyle rule, because they'd defined a TestRule in their foo-ete project, in the src/main/java directory.

I think whitelisting the assertThat one is low regret

@iamdanfox
Copy link
Contributor

I think it's because this PR came from your personal fork, and changelog-app's repo-specific doesn't have perms on your fork sadly. We've recently granted all palantirians write access to our OSS repos to workaround this.

@carterkozak
Copy link
Contributor

changelog bot... bump?

@pkoenig10
Copy link
Member Author

Moved to #915

@pkoenig10 pkoenig10 closed this Sep 30, 2019
@pkoenig10 pkoenig10 deleted the imports branch September 30, 2019 20:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants