-
Notifications
You must be signed in to change notification settings - Fork 461
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 Tests #530
Add Tests #530
Conversation
Add tests for the following cases: * Empty pattern passed to spotlessFiles * A pattern that matches no files passed to spotlessFiles * Invalid regexp passed to spotlessFiles * Spotless is configured with a Kotlin build script Also a little reorganization, and a change required to support Kotlin build script was added to GradleIntegrationTest.java so that other tests can make use of it.
I do not see a |
We use This all looks good to me, except for the changes to I like Kotlin, I'm all for people using kotlin build scripts, but I don't think we need to use it in all/any of our tests. I'm fine with you using it in this test, but I don't want to push it into the infrastructure.
I think probably it should format nothing. But most of all, how are you using this feature? What are you connecting to? My vote is to fix what is broken for your usecase. I care a lot about Spotless being clean and correct, and I think this particular feature is deeply, irrevocably dirty. I let it in, years ago, to help someone solve their problem. I'm happy to let you merge whatever you need to solve your problem. But I do not want to spend a lot of time engineering every corner-case of this escape hatch. |
The
Fair enough. In an ideal world, Gradle's support for plugins should be agnostic to the language in which the build is configured. I know it's a rule of unit testing to only cover the system under test, and Gradle's Kotlin build script support is not part of the system under test. In practice, though, I found a number of differences between the two, and, even though it did not actually end up affecting my use case, I could see those differences causing bugs. I just think it would be nice to be aware of these potential problems before they happen
I'd like Spotless to format no files in the case that my I do want to say that it seems odd to me that applying Spotless only to changed files has been considered a corner case up until this point. I know you have an issue open to add more proper support for this, but that has always been a very important use case for me. Incremental style compliance is extremely useful when changing the style rules or applying new ones to an existing system. Those huge PRs that touch all of your files are really scary to me and impossible to review, so I greatly prefer to fix the style issues as I make other changes to files. Anyway, I'll make the requested changes in the morning. Thanks! |
Apologies, my mistake. Moving the Kotlin-specific change out of
Agreed! Just hasn't made it to the top of anyone's todo list. Probably because the cost of swallowing one "format the world" commit has always been less than implementing this feature. |
* Remove Kotlin support from GradleIntegrationTest and move it into SpecificFilesTest * Add information about the change to the [Unreleased] tag in CHANGES.md
Ah yeah, that makes sense. Anyway, I've uploaded the requested changes. PTAL |
Thanks for all the support, Ned! |
Thanks for making the test better 🥂 |
FYI, |
fixes #529
Changes
Add tests for the following cases:
Also a little reorganization, and a change required to support Kotlin
build script was added to GradleIntegrationTest.java so that other tests
can make use of it.
I'd be more than willing to also fix the IntelliJ warnings (unused method, unnecessary
throws
, and access modifiers that can be more restrictive) inGradleIntegrationTest.java
if you'd like. As a rule of thumb, I generally do incremental style fixes when making other changes to a file (in a separate commit, but the same PR. Happy to break this convention if you prefer).Suggestion
Perhaps consider renaming
GradleIntegrationTest
. Maybe something likeGradleIntegrationTestHarness
would be a better name. In my experience, it's best practice for the names only of test classes to end inTest
, rather than also doing so for testing infrastructure. For example, I sometimes will search the test source directory with the intent of only looking at testing infrastructure, rather than tests. I actually did so in writing this change. Sometimes people get around this by putting their test classes in a separate directory from testing infrastructure, though this does not appear to be the case for Spotless. This makes proper naming of testing infrastructure especially important. Even in other cases, I still see it as the cleaner naming convention. I'd be happy to make this change, if you'd like.Question
When an empty pattern is passed to
spotlessFiles
, what should be the behavior? The test I've written currently assumes that the correct behavior is for Spotless not to format any files. Note that this is not the way Spotless currently behaves: It currently acts as thoughspotlessFiles
is unspecified and formats all files matched bytarget
. I have added an@Ignore
annotation to that test case.