Testing Considerations

[Ryan Riley]

Something I would appreciate as one who like unit testing is a way to test my pagelets, formlets, etc. for structural expectations and client/server function validation. I trust WebSharper to generate the right output, but I don't always trust that I wrote the correct logic, and having to test on the client somewhat defeats the purpose of writing all of my code in F#. Is there a possibility to unit test the intermediate output? In other words, could I test that the F# object representation of my page matches my expectations? (I could see attaching my test.xml output and having WebSharper generate the F# structure for me as an option.) Also, if I call my [<Rpc>] function, which I can test, how can I test the result of my [<JavaScript>] call of that function? I'd love to be able to verify the results of calling the [<Rpc>] and handling the result.

Thoughts?

[Dmitri Nesteruk]

But surely there are, really only two states - the initial F# state, and the final JS state. In this case, you can test the F# logic in its 'compiled' form using FsUnit or similar, whereas for the JS site you would use something like QUnit. I can see where you're going with this, in terms of being able to write F# tests using some sort of binding to QUnit, so that ALL tests exist as F#. That could actually make sense.

I actually disagree with your idea of not having to validate WebSharper, because I think that you have to ensure that the translation has 100% fidelity. There's no escaping it, whatever transcompilation technology you choose.

[Anton Tayanovskyy]

Hi Ryan,

I agree that testing landscape can be improved for WebSharper, but can
we discuss/brainstorm for more specific features you'd like to see?

As Dmitri points out, two parts of the puzzle are simple: F#-side code
including RPC methods can be tested as F# code, JavaScript-side
library code should be tested on the client if possible.

Client-side formlets are perhaps the most difficult to test, maybe
Joel will have more ideas on that.

Testing sitelets seams quite feasible. Can we narrow this down a bit,
do you have a specific example of what you would want to verify? You
can write it here and I can try turn it into actual working code.
Thanks!

As for testing translator correctness, at the current state of
WebSharper you'll do well to test it. As we get better with it, more
and more problems (ideally all in the end) with the translation will
be detected at compile time - to either work as expected or fail with
a message. In general I also hope testing as a software engineering
practice should gradually give way to proving. Maybe I will still live
to see a Coq-formalized JS semantics, coupled with some F# or CoreML
semantics, and a certified compiler :)

Anton

--
Kind Regards,
Anton Tayanovskyy

WebSharper™ - type-safe JavaScript in F#
http://intellifactory.com

[Anton Tayanovskyy]

Hi,

There is also a tool for integration testing that we played with
internally that we might release one day: basically it is a crawler
running PhantomJS. The idea is simple: during a test build you fire up
a development server, run the app, and start crawling from the root
page everything you can find. PhantomJS is a command-line app that
includes a WebKit browser, so it is aware of JS errors on any of the
pages and it can report them.

Anton

[Ryan Riley]

On Jul 14, 2011, at 5:11 AM, Dmitri Nesteruk <dmitrin...@gmail.com> wrote:

But surely there are, really only two states - the initial F# state, and the final JS state. In this case, you can test the F# logic in its 'compiled' form using FsUnit or similar, whereas for the JS site you would use something like QUnit. I can see where you're going with this, in terms of being able to write F# tests using some sort of binding to QUnit, so that ALL tests exist as F#. That could actually make sense

I hadn't thought of bindings for QUnit, but that could certainly work, as well as satisfy the issue below.

I actually disagree with your idea of not having to validate WebSharper, because I think that you have to ensure that the translation has 100% fidelity. There's no escaping it, whatever transcompilation technology you choose.

I'm a big fan of not testing frameworks in project tests. Then again, you make a good point that I need to know that what I wrote compiled into what I expect.