I'd prefer not to break out the CLI into a separate repo just because IntelliJ not supporting sbt integration tests. It's nice to have the CLI tightly integrated with everything else. It's also used for created release, so being in a separate repo complicates that a bit.
This technique of using a regular expression to ignore integration tests is reasonable to me and I found plenty of people mentioning it, so this isn't an uncommon problem. Another option is to upgrade to JUnit 5, which allows you to give tags to tests. We could then tag all the integration tests with a special tag and then document how to ignore those tags in IntelliJ. A post on stackoverflow [1] talks about these two options. - Steve [1] https://stackoverflow.com/questions/13104357/excluding-tests-from-being-run-in-intellij On 3/12/19 9:40 AM, Beckerle, Mike wrote: > If we can simplify things and have IDEs just view the daffodil project > tree/nest "normally", that is a big win vs. having a bunch of customizations > in sbt that are hard to maintain. > > > I'm willing to sacrifice scala-debug convenience, and sbt it:test convenience > for this. > > > Do we have to break the CLI out into a different subtree entirely? > > Maybe that is ok though. CLI is effectively an application of Daffodil's > libraries. Maybe it should be separate? > > > ________________________________ > From: Steve Lawrence <[email protected]> > Sent: Tuesday, March 12, 2019 9:20:32 AM > To: [email protected] > Subject: Daffodil IntelliJ Support > > I've taken a look at what changes are necessary to support IntelliJ, and > found two main issues, both kindof related. > > 1. The first issue is our "debug" configuration. This is used to > separate tests that are known to fail from working tests, while still > allowing us to easily run failing tests via "sbt debug:test". This > configuration ends up confusing IntelliJ and it doesn't add the the > working test jars to the classpath. Only the debug test jars are on the > classpath. > > Thoug, I'm not even sure we really need scala-debug anymore, so I > propose that we just remove those directories and move the failing tests > to test/scala and comment them out. If we want to test debug tests, we > can just uncomment them. Removing the debug configuration from sbt > allows IntelliJ to find the correct classpath for normal tests. > > 2. IntelliJ does not support sbt integration tests. This is basically > the same issue as scala-debug, but for some reason IntelliJ finds the > right classpath for test jars. However, this means the integration test > jars are not on the classpath. So if you try to run all tests, it ends > up complaining that it can't run the integration tests in the > daffodil-cli modulue, causing it to not run any tests. > > I'm not even sure it's wroth trying to run the integration tests in > IntelliJ, so I'm not sure this is something worth trying to support. > Fortunately, all of the integration test classes start with "TestCLI", > so it's not too hard to run all tests except these. > > > So assuming we remove the scala-debug configuration, the following steps > allow IntelliJ to work and run all tests: > > 1. Import Project > Select Daffodil directory > 2. Import project from external model > sbt (make sure to have the sbt > plugin installed) > 3. Check "download library sources" > 4. Check use sbt shell "for imports" and "for builds" > 5. Uncheck allow overriding sbt version > 6. Global settings > Maximum Heap size: 6144 MB > 7. Finish > 8. Build > Build Project (this should use SBT, output in the sbt shell) > 9. Run > Edit Configurations > 10. Click the Plus (+) > JUNit > 11. Name: Run All Daffodil Tests > 12. Test Kind > Pattern > 13. Pattern: ^(?!.*TestCLI.*).*$ > 14. Search for tests: In whole project > > With these steps, I was able to get IntelliJ to run all tests except for > the integration tests. > > Unfortunately, about 50 tests still fail, but I think they all look to > appear to be related to ClassLoader issues or finding some tests. I > suspect these need code changes to be resolved. > > - Steve >
