I've been working on a bunch of related geometric packages and one thing I haven't quite figured out is the best way to structure test code. So far I've been using the fairly common pattern of having a 'test' subdirectory with its own elm-package.json that has "../src" in its source-directories and dependencies on testing packages (currently elm-test and elm-check) above and beyond the dependencies of the base package.
This works, but it means that I can't share testing functionality between packages. For example, in one package I define producers (a.k.a. generators/fuzzers) for things like Point3d values. In a separate package, I'd like to create a Triangle3d producer by combining three Point3d producers, but I can't because the Point3d producer is hidden inside the first package. One solution would be to define actual tests in a subdirectory as now, but put shared test functionality (producers, comparators etc.) somewhere in the base package. This means anyone depending on the root package could have access to its defined producers etc., but it also means adding any testing libraries as dependencies of the root package instead of the hidden testing sub-package. An alternative I thought of would be to have a separately-published test package (e.g. package.elm-lang.org would have both "my-package" and "my-package-test"), with the test package depending on the base package. The test package would expose shared functionality like producers and comparators. During development, you'd have to check out the sources for both the base package and the test package, and replace the test package dependency on the base package with a relative path to the base package checkout in source-directories (so that you could add functionality to the base package and immediately add tests for it without having to publish the base package first). When it comes time to do a release, you'd publish the base package, update the test package to depend on the published version of the base package instead of having a relative path in source-directories, then publish the test package. This way anyone could just use the base package without pulling in any unwanted testing dependencies, but could also depend on the testing package if they wanted to use the exposed producers etc. in their own test code. Thoughts? Are there better ways to do this? -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
