Testing Elm Code (Revisited)

[Max New]

So now that ports are out, I've used them to implement a little script to test Elm code using Node. I based it on Alex/deadfoxygrandpas's Elm-Test, but updated to work with the latest Elm compiler and separating runners so you can run as a webpage or as a command line tool:

https://github.com/maxsnew/Elm-Test

A few observations:
1) Ports like stdout and exit can be used as a replacement for `main`. This leads me to believe that main should be deprecated in favor of being a port itself (like `document`).
2) I use a hacky bash script to put a handler in for the `exit` port, but this could be a built-in port.
3) I also needed the bash script to put the elm runtime into one big js file. Perhaps this would useful as some sort of `elm --standalone` command?

Of course the bash script could also be replaced by some Haskell in the Elm test-suite.

I'd like to put this in the Elm repo as soon as possible but a barrier I see is that the Elm-Test repo exists as a standalone item and so would ideally be distributable as a library elm-get. I don't know how to make the elm test suite depend on elm-get but it might be possible. If the library were wholesale included in the Elm repo, however, testing would be trivial and maybe it could be released on elm-get the same way the base libraries are.

[John Mayer]

I was able to use the vm module in node to do some loading of code.

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Antti Rasinen]

Speaking of Node, I had some time to make my wrapper into an npm module. See https://npmjs.org/package/elmloader and https://github.com/arsatiki/elmloader

I quickly tested out jsdom as a DOM replacement, but it brought in such a massive amount of dependencies. Maybe later, if implementing a missing feature really requires it.

—Antti

[Max Goldstein]

I'd like to make an argument for keeping main not a port: simplicity for newcomers. Learning a specific instance of a general pattern is fine if that pattern is essential, but by making main a port, you're requiring (or at least implying) that new users must master the FFI before they get anywhere. Evan has said he wants new users to to need to learn as little as possible before they can write Elm code. Contrast Haskell monadic I/O....

[Jeff Smits]

I think that for a limited set of things a newbie can be told "this is just the way it works". We already do so by calling main a special value that can be of type Signal Element or Element. Special syntax like port may just make it easier, showing that main is a special value. In a tutorial you can just mention that it's a known unknown but it's ok because you won't need to know that unknown until you get to "chapter X: Elm interop with JavaScript using Ports".

On Sat, Jan 25, 2014 at 12:20 PM, Max Goldstein <maxgol...@gmail.com> wrote:

I'd like to make an argument for keeping main not a port: simplicity for newcomers. Learning a specific instance of a general pattern is fine if that pattern is essential, but by making main a port, you're requiring (or at least implying) that new users must master the FFI before they get anywhere. Evan has said he wants new users to to need to learn as little as possible before they can write Elm code. Contrast Haskell monadic I/O....

--