Add testing section to hyperHTML docs

[grommett]

This PR:

• Adds a brief description about testing
• Shows a sample test suit for testing a simple hyperHTML component or element

It might be a good idea to add a "Testing" section to the docs. The intent is to show that it's testable and it's not required to have a special library to test, other than a JavaScript DOM implementation. This is not a distinguishing feature, but I found writing tests to be much easier than with React using Enzyme as there was nothing extra needed other than what one already knows when working with vanilla JS and the DOM.

The test might be too long for a simple example (maybe break it up?) by adding Sinon, but I wanted to show how easy it was to also test interactivity.

[WebReflection]

This is awesome but I think it needs few adjustments.

To start with, I would put testing after the components section instead of before the API. As important as these are, knowing "how" to test without knowing "what" seems a bit like a reversed order (if you're not an extreme programmer).

If that's OK, please move the section down after, right before the Extras.

You will, however, need a JavaScript implementation of the DOM

This is not accurate. The library itself is 100% test-covered on both server and client.

Accordingly, you need a JS implementation of the DOM only where you don't have a DOM.

Examples are NodeJS, NativeScript, or even Service Workers (https://github.com/WebReflection/hyperSW), if it makes any sense to test hypreHTML inside a Web Worker (it does if you need it).

The test example code is compact enough, no need to split it, but while I don't mind using Sinon in there, it might be worth mentioning that any testing framework would do, even just console.assert(cond, msg) (which is basically how I've covered 100% the library in all targets).

Last, but not least, a one liner like

npm install basichtml hyperhtml sinon

// with optional
node test.js

would probably help newcomers even more!

Thank you again for the huge documentation help!

[grommett]

My pleasure to help out.

knowing "how" to test without knowing "what" seems a bit like a reversed

This is a good point. I'll adjust.

Accordingly, you need a JS implementation of the DOM only where you don't have a DOM.

I'll clarify this point. It's what I meant to say when I said:

hyperHTML is easy to test in a Node environment

I think the one liner is a great idea. I'll add that.

[WebReflection]

It's what I meant to say when I said: hyperHTML is easy to test in a Node environment

apologies I didn't see that after a quick read. Although, since I already missed that out, maybe it's good to say it's easy to test on browsers and just adding a DOM env in NodeJS, otherwise the testing section would look focused more on node than browser.

This is a browser targeting library, even if Node is what I use to show the 100% code coverage badge, browsers tested against the library is the real thing I care of.

Hope this makes sense

[grommett]

I've updated the ordering and tried to make the distinction more clear that you can test in either a Browser env or Node.

The main change with this update is that I created links to working samples in each environment for the reader to view. Codepin & RunKit.

Trying to create samples for each environment made the section way too long for the emphasis it requires.

[WebReflection]

OK, merged .... probably too early.

There is something wrong with the Code Pen example, it's an infinite loop.

On the NodeJS one though, you didn't have to use tressa, you can just use either sinon or console.assert or the native nodejs assert, whatever, really.

Thanks for fixing the Pen example

[WebReflection]

Removed the link to the Code Pen 'cause I think that infinite loop is not good to anyone.

Please pull rebase before pushing an updated version or let me know when the example is fixed.

Thanks a lot

[grommett]

Weird. The pen was working fine earlier, but now I just went back and it works intermittently for me too. I'll investigate.

Sorry about that. I'm not sure what could be causing that.

[grommett]

Without any changes the Pen seems to be working consistently for me now. Are you seeing the same? I wonder if it was a problem with Codepen or one of the servers serving the dependencies?

[WebReflection]

I see this, problem not solved.

[WebReflection]

Right ... this is why I love to keep things simple ... 3 external dependencies that aren't working as expected just to show how to test something testable via just console.assert ... :smile:

If you cannot solve the issue (I've tried and failed) I think I might create a simple test that has no dependencies.

I don't want to explain in this documentation page how to fix 3rd parts libraries, thanks for your help and understanding.

[grommett]

I completely agree with you. Mocha is nice for the output. And Sinon for the spies, but definitely not necessary.

In any case I've removed everything and just using console.assert & hyperHTML + Babel.

[WebReflection]

I don't know what's going on but it keeps doing the same reloading.

So, I went ahead and created this.

https://codepen.io/WebReflection/pen/OjQqYg?editors=0010

If you like the example, I'll push my version (your one still flicks like crazy)

[grommett]

Please push yours. I would change the messages in yours though since the current messages are for failures. [Edit: it looks like you already did]

I have no idea why this is happening to my pen...oh well.

Sorry for the churn on this simple task!

[WebReflection]

Done!

[WebReflection]

P.S. I've just noticed RunKit is incompatible with Bash/Shell/Terminal layout so it shows stuff like "\u001b[32m✔\u001b[39m <p> length" instead of what TravisCi, as example, would show :disappointed:

[grommett]

Yes, I noticed that too. 😞 I'm not aware of a similar service, are you? The intent is to show a working sample in Node and I think it does the job. Even if the output is not ideal.

[grommett]

Well it sort of does...If you click the arrows you can see the formatted output, but most won't: