Run local tests #1
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
elm/core is special because the compiler always inserts an implicit dependency on it. therefore it's impossible to have the tests integrated in the elm/core project in the normal way -- if we try to symlink out from $ELM_HOME to our project's source in the way that was done for 0.18, the compiler gets into a deadlock. other approaches cause it to find two copies of all the code in elm/core and refuse to proceed. instead, this approach creates a logically independent project, with no real code, only tests.
these are no longer required by the new version of elm-test
* Date is no longer part of elm/core; remove tests for it * need to import Debug.toString to test it now * 0.19 limited tuple size, so reduce test to match * use new modBy and remainderBy functions * 0.19 removed flip, curry, and uncurry; so, remove tests for those * updates for elm-test: * remove a duplicate test * use Expect.within with floats
* expose Array module contents w/o prefix rather than Maybe * use modBy instead of (%) * remove test for Array.toString, removed in 0.19
* shadowing is no longer allowed by the compiler; remove test for it
* elm-test now requires tests to have unique names
* update import syntax * use String.fromInt, modBy, and Tuple.pair rather than toString, (%), and (,) * inline our own version of flip, as it was removed in 0.19 * remove test for scanl, which was removed in 0.19
* use modBy rather than (%) * String.toInt now returns a Maybe rather than a Result, so implement our own local version of the old behaviour, so the andThen tests can continue to build upon it.
* String.toInt and String.toFloat now return Maybe * String.toInt no longer parses hex literals in 0.19
these are no longer required by the new version of elm-test
* Date is no longer part of elm/core; remove tests for it * need to import Debug.toString to test it now * 0.19 limited tuple size, so reduce test to match * use new modBy and remainderBy functions * 0.19 removed flip, curry, and uncurry; so, remove tests for those * updates for elm-test: * remove a duplicate test * use Expect.within with floats
* expose Array module contents w/o prefix rather than Maybe * use modBy instead of (%) * remove test for Array.toString, removed in 0.19
* shadowing is no longer allowed by the compiler; remove test for it
* elm-test now requires tests to have unique names
* update import syntax * use String.fromInt, modBy, and Tuple.pair rather than toString, (%), and (,) * inline our own version of flip, as it was removed in 0.19 * remove test for scanl, which was removed in 0.19
* use modBy rather than (%) * String.toInt now returns a Maybe rather than a Result, so implement our own local version of the old behaviour, so the andThen tests can continue to build upon it.
* String.toInt and String.toFloat now return Maybe * String.toInt no longer parses hex literals in 0.19
This will allow us to run tests on local elm/core.
This commit makes the tests into a mock package called `elm/core-tests`. This stops the compiler complaining about kernel code and allows the tests to run localy. `elm-test` does not allow such a hack so the tests have to be run locally. When building a package, elm expects absolutely all source files to be in the `src` directory. Therefore, before running the tests some copying and pasting is required.
harrysarson
force-pushed
the
local-tests
branch
from
9f4f578 to
6eadaf5
Compare
|
I think that your solution could well be better here, it allows the tests to be run using the node test runner which creates much nicer output to the terminal. |
|
Thanks for lending a hand! I refined my approach a bit, and will probably However, I'm far from an expert on how this really ought to be done -- I just wanted to get something working so I could test my fix to elm#1011. :) I am planning to open a PR for my approach, but I'll certainly link back here so Evan et al. can pick whichever approach they prefer. |
|
I prefer your approach 👍 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi I saw https://discourse.elm-lang.org/t/running-tests-for-elm-core/3073/4 and thought I would have a go at running the local tests and this is what I came up with!
I see that since I started this work you have also looked at running local tests (via
run_tests.sh) but I think that as my approach is slightly different you may be interested in it.I make the
testsdirectory into an elm package and copy the core modules, tests and some runner code into thetests/srcdirectory. I can then run elm make (the compiler does not complain about kernel code because the package is calledelm/core) to build the tests.Would be interested to hear what you think about this approach!