How could a pure go test go about testing dom element creation/modification?

[BF]

Is there anyway to make go tests that involve creating and modifying dom elements by using gopherjs? The current issue i've encountered is that js.Global.Get("document") returns null, making it impossible to create dom elements in a go test. Are there any ways to mock out a document that could return dom elements or would this kind of testing require using the go code as transpiled javascript?

[Larry Clapp]

I've also looked into GopheJS UI unit testing.  You have a couple of options.  I chose writing QUnit tests and running them in an actual browser.  See https://github.com/gopherjs/jquery/blob/master/test/test/index.go for examples using QUnit to test the GopherJS JQuery binding.  I don't have any of my own code to share, sorry.  It's all pretty preliminary at the moment anyway.

Other options include HtmlUnit and Selenium.

Also Google "dom unit testing" for some other ideas and approaches, including a StackOverflow suggestion to mock the bits of DOM interaction you do.  (For myself, I barely know web development or jquery and am pretty leery of trying to mock them accurately.  Also, I'm trying to use VueJS, which needs a real DOM anyway (as near as I can tell).)

PhantomJS (a headless browser) and mock-browser (a Node.js module that mocks a browser within Node) are also possibilities.  GopherJS runs well on Node (as I understand it; I don't think I've tried it), so that could be promising.

There's no tried-and-true answer (yet), unfortunately.

Let us know what option you choose, or what further challenges you run into.

-- Larry

[Bjørn Erik Pedersen]

This may not be your solution to your problem, more like an inspiration:

https://github.com/bep/gr/tree/master/tests

These are all GopherJS tests -- but they interact with Facebook React's shallow rendering feature ... It is very pleasant to not have to deal with a DOM, browser etc.

bep

[BF]

The solution that I ended up taking was to create an interface for a dom element (appendChild, setAttribute etc) and I have one implementation that uses a *js.Object and implements those methods through js calls and I have another mocked implementation that keeps track of these methods using go fields. It uses a map for attributes and styles, a parent reference field and a slice of children. It does require implementing these functions in go which requires matching the behavior of dom elements and could causes the mock to behave differently than a real dom element, but I believe the pay off for detailed unit tests is worth it. I've also added some smoke tests in a js client that use and verify exposed methods from the transpiled go code to verify dom interaction is working.