Spectron/Webdriver integration test example

asticode / go-astilectron-demo

Discover the power of Astilectron through a demo app

MIT License

404 stars 83 forks source link

Spectron/Webdriver integration test example #62

Open chinenual opened 4 years ago

chinenual commented 4 years ago

I've tested this successfully on both Mac and Windows. I'm getting a mystery error on Linux, and I'll continue to investigate since I need this to work on Linux for my project.

But I'm pushing this now so you can review and let me know if you would like it restructured or changed.

One known limitation: the test won't work unless the electron artifacts have been provisioned (the readme warns that you need to run the application once manually before trying to test). I think I coud fix that by calling the default provisioner from my Adapter -- but the default provisioner isn't exported from astilectron package and its probably not clean to copy/paste it into the demo. I could do a PR to expose the default provisioner (as you do with the DefaultExecuter), if you agree?

chinenual commented 4 years ago

@asticode - Quentin - this PR hasnt gotten any comments - should I take it that you are not interested in integrating the test example into the demo? If not, that's OK - I'll create a new repo and put the example there.

asticode commented 4 years ago

@chinenual to be honest I came back to this PR a couple times but it always felt like it belonged to another repo. Creating a new repo seems like the best idea, we could add a link to it in the README though

chinenual commented 4 years ago

@asticode Sounds good. I'll let you know when its ready with a PR for the README? I plan to call it chinenual/go-astilectron-uitest unless you have a preference for something else?

asticode commented 4 years ago

Feel free to name the repo as you wish, but I think it's a good choice 👍

chinenual commented 4 years ago

@asticode - I'm having some trouble deciding how best to structure this. The ui-test requires a small change to the main.go (to set the executer and allow the test driver to set the tcpport) and in a real project it would be part of the project; not a separate repo. I really don't want to copy/paste all of the demo into the test example project, but am not sure the best way to explain

what needs to be changed in the main.go
how to copy the test boilerplate into a subdirectory of the application project (can't just git clone into a subdirectory without also explaining that the test's .git directory then needs to be removed). The cleanest way to do it would be to keep the ui-test as a separate repo so it sits along side the main project instead of within it. That's not how I've traditionally structured test code (and it seems it would complicate CI setup). But perhaps it would be acceptable?

Ideas on best way to structure this?

asticode commented 4 years ago

I think your repo should be a ready-to-be-run project with a nice README. Maybe don't copy/paste the demo project, but you'll need to set up a minimalist project using the bootstrap and the bundler (with a simple .html page showing Hello World for instance).

what needs to be changed in the main.go

The only solution I can think of is a nice README

how to copy the test boilerplate into a subdirectory of the application project

Either explain what needs to be copied in the README, or encourage developers to git clone your repo to test the process using your test project. Then, once the repo has been already git cloned, they can safely copy the content of the directories.

chinenual commented 4 years ago

Agreed. I'll let you know when I have something ready.