mkobit / gradle-test-kotlin-extensions Goto Github PK

reduce clutter and make it more obvious which methods are apart of it and are not.

cons:

• more imports and discovery
• probably breaking

• https://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#getOwner(java.nio.file.Path,%20java.nio.file.LinkOption...)
• https://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#setOwner(java.nio.file.Path,%20java.nio.file.attribute.UserPrincipal)

Some tests would like to do the following

• build(arg1) - assert on build result
• build(arg2) - assert on build result

Where the arguments between the first and second build are different.
In most cases I find myself wanting to keep most of the options like --stacktrace and --info while only changing the tasks that are executed. This will be sort of problematic with how the GradleRunner APIs work.

This currently requires some thought as mixing both arguments and options does not work incredibly well together and the APIs are still pretty meh to use.

I think this will result in API changing to provider a more "base runner" context and then copy/run builds from that. The BuildResult is what will be queried anyways afterwards.

Figuring out the right API here is the most important part.

TODO: Propose a better API that accomplishes the following:

• Produce new build executions for same project directory with default (preconfigured) arguments
• Append additional context to new build execution
• (Possibly) mutate default (preconfigured) arguments

Assumption here is that the project directory is reused

Right now, the RegularFileContext.content getters/setters are for ByteArray to not make assumptions about encoding for users and also better translate to what the Files APIs do. This still isn't friendly so might be revisited.

Being able to also just set the content as a String or CharSequence would most likely be easier for most users, so maybe it should be the default?

Right now:

FileContext.RegularFileContext(path).content = "stuff".toByteArray()

this would enable it to also be

FileContext.RegularFileContext(path).content = "stuff"

dependent on https://youtrack.jetbrains.com/issue/KT-4075

follow up from #43

I thought I changed this but apparently not. String interning or constant pool might unintentionally cause it to be equal when it shouldn't be. To get around it just make it object Original : CharSequence

in addition to Java 8

See if anything is useful and add them

https://docs.gradle.org/current/javadoc/org/gradle/testkit/runner/BuildResult.html

Works better in DSL-like code and doesn't require as many .toByteArray()

append to file case

file.content += "more content"

https://docs.oracle.com/javase/8/docs/api/java/lang/Appendable.html

follow up to #35

Change to @Deprecated(level = DeprecationLeve.ERROR)

The Kotlin plugin automatically resolves version based on plugin version used, so you can do api(kotlin("stdlib-jre8")). Unfortunately, the version is not also in the POM

Easiest fix is to just explicitly use the same version

Should also follow up with a YouTrack issue for patching the Kotlin Gradle plugin for publishing

    <dependency>
      <groupId>org.jetbrains.kotlin</groupId>
      <artifactId>kotlin-stdlib-jre8</artifactId>
      <scope>compile</scope>
    </dependency>

see https://issues.sonatype.org/browse/MVNCENTRAL-2870

will allow for rerunning a build multiple times with slightly different build.gradle

dependent on https://youtrack.jetbrains.com/issue/KT-4075

DSL setter overloads would be useful in a lot of parts. Some areas the API is mostly a decorator around something like Files.write(Path, ByteArray). Doing file.content = "hello".toByteArray() is not as convenient as doing file.content = "hello".

See if anything would be useful

https://docs.gradle.org/current/javadoc/org/gradle/testkit/runner/BuildTask.html

• https://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#getPosixFilePermissions(java.nio.file.Path,%20java.nio.file.LinkOption...)
• https://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#setPosixFilePermissions(java.nio.file.Path,%20java.util.Set)

see https://kotlinlang.org/docs/reference/operator-overloading.html

possible functions:

• FileContext.DirectoryContext
  • operator fun String.invoke(action: FileAction, setup: FileContext.DirectoryContext.() -> Unit) - apply action to file path (file or directory?), and do setup on it
  • operator fun div(action: FileAction, directoryName: CharSequence) - create or get directory at path
• FileContext.RegularFileContext
  • operator fun plus(bytes: ByteArray) - append bytes to file
  • operator fun plus(content: CharSequence) - append toString() to file with default encoding

DSL thoughts:

runner.setupProjectDir {
  "src" {
    "main" {
        "java" {
          "MyFile.java"("public class MyFile {}")
        }
    }
  }
}

I've found myself using it more often for file assertions where I want to check paths inside of the project directory so performing !! when it is assumed to be non-null is annoying

• - should we keep the current div syntax for constructing DirectoryContext and nested DirectoryContext?
• - should we keep the current string invocation methods for creating a RegularFileContext inside of a DirectoryContext?
• - should RegularFileContext methods accept a character encoding, or should it only be done at construction time?

http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html

As a developer I want to retrieve the Path from the GradleRunner so that I can use NIO APIs to set up test projects more easily.

from com.mkobit.gradle.test to com.mkobit.gradle.test.kotlin

so that there are no split package problems when moving to Java 9

https://github.com/arturbosch/detekt

Add in contracts support as well

    public operator fun CharSequence.invoke(
        fileAction: FileAction = FileAction.MaybeCreate,
        action: DirectoryContext.() -> Unit
    ): DirectoryContext = directory(this, fileAction, action)

Right now the UX is like this:

gradleRunner.setupProjectDir {
  "build.gradle" { // DirectoryContext
  }
  
  "build.gradle"(content = Original) { // RegularFileContext
  }
}

It is more consistent and expected for these both to return a RegularFileContext

• Reduces amount of parameters for each DSL method
• Clearer creation of files with certain charsets

Idea is to overload the div operator for possibly more fluent directory expanding

radleRunner.setupProjectDir {
  this / "dir1" / "dir3" / "dir4"
  this / "dir1/dir2/dir3"
  "dir1" / "dir2" {
    // DirectoryContext for "dir2"
  }
  "dir1" / "dir2" {
    "dir3" / {
      // DirectoryContext for "dir3"
    }
    "file1" {
      // RegularFileContext for file1
    }
  }
}

Combined with #27 it might be easier to create nested file is directories that may be mostly empty. For example, files in deeper Java package structures.