System Tests #1996
base: master
Are you sure you want to change the base?
System Tests #1996
Conversation
ade9ebd
to
4c9cc28
Compare
Thanks! This will be great to get working. |
Not sure how to use taxi's send-keys method with switch-to-active return value... |
Hm, made a issue ticket on clj-webdriver for discussing semantics of taxi/switch-to-active. IMO this probably won't be used too often. We can create a simple function called "current-element" which can be used as the query value for taxi if need be. |
@justintaft FYI, let's use this PR for ongoing discussion. |
There is a command "Dev: Open Developer Tools". This shows the familiar developer tools in chrome. Easy way to inspect the DOM =). We should have a system test for creating, saving, and loading a file. However, a native file dialog window pops up during these processes and you can't use web driver to click save. In other projects I've wrote a program to click native buttons, but it was always a hacky solution.... anyone have a better suggestion? This file dialog window also appears when adding a file/directory to the workspace tree. For now I can keep things simple. I'll create a temporary file, launch the editor passing in the path to this file, verify the contents are correct, modify the contents, save, then verify the changes have been stored to disk. Since the file exists, we won't have the dialog window pop up for now... |
@justintaft Would it overly defeat the purposes of these tests to fake or mock the native OS UX? We don't need to test it directly – it should be enough that the fake or mock returns specific values to the calling code. |
This should be ok. If not done so already, their should exist a cljs function used to show the dialog window. This will contain the electron call to show the native file window selection screen. We can then assert this code is correct in a test, and then replace it with our mocking code. |
Needs a bit of refactoring, but the dialog window should be mockable now =). |
@justintaft Nice! |
@justintaft We have a QA checklist of tests to do manually prior to release – these would be great to automate. |
@kenny-evitt Thanks =) Hopefully once I get everything bootstrapped I can get some help from the community. Ok, so I wrote the code for the mock dialog window. Question is, how do we inject this mock? Few options: Is there a way to sandbox light table so it won't find my personal user behavior file & installed plugins? |
Ah alright, looks like the "user" directory is overridable. LightTable/src/lt/objs/files.cljs Line 360 in 1d9dd0c
As for injecting the mock, I'll go the plugin route for now, unless otherwise suggested =). |
@justintaft A plugin seems perfectly fine. |
Added some assertions for saving & loading a file. I couldn't use I added some nasty timeouts in the code, they should be replaced with some function that continually polls until some condition is met, and errors out after a certain time if it doesn't. I have an example in the code for actions (moving up to an editor tag and clicking the "x" button). This will be similar for dragging tab tests. Also, going to try and get chromedriver&webdriver working on travis-ci. |
37944dc
to
6e668a3
Compare
Save any local work before using scripts below script/run-tests.sh should run the automated tests. It downloads & starts chromedriver, and then runs If you need to download the mac version of chrome driver, then uncomment the mac line in run-tests.sh. Lastly, light table doesn't initialize all the way for whatever reason when chrome driver is running. Running "lein test" a few times usually gets the tests running. You might have to kill the old light table process if it hangs. |
@justintaft This is really great work. 👏 I'm working on manually QA-ing the 0.8.0 alpha release now but I'd like to try to cover those tests with this stuff. |
It looks likes the tests are running on travis =). I expected 1 to fail and 2 to succeed. The failing test was was to verify the tests actually run. https://travis-ci.org/LightTable/LightTable/builds/83831752#L443 Also, https://github.com/LightTable/LightTable/pull/1996/files#diff-60356cebc67cdde1a0e1379669a603e5R40 . I'm running bash and passing in a script to start LT. This is so I can redirect STDERR and STDOUT in the bash script, without adding some try/catch blocks inside the cojure test suite to capture the output shell/sh if an exception is thrown by web driver. This...is kind of nasty. |
Found a cygwin appveyor.yml project example |
Windows CI setup is coming along. I still need to download chrome for windows & unzip in the right place. The console output is looking good though. https://ci.appveyor.com/project/kenny-evitt/lighttable/build/1.0.36 |
@justintaft looking good |
9310a30
to
88b649b
Compare
@kenny-evitt tests are running on windows AND linux now =) Again, the failure is expected |
@justintaft Thanks for working on this. What's next? |
1442869
to
dedeaae
Compare
39d11c9
to
ac7d56f
Compare
Most* of the bullets of the QA should be converted to checkboxes so that we can tick the ones that you have already covered. Did you you finish 1. and 3.? If so good job! * not everything can be tested […] |
#1 is taken care of. I implemented a polling function which re-runs until it passes (ie, waiting for an element to become visible). Default is wait 1 second at most, and re-try every 100 ms. #3, I cleaned up the code a bit but it honestly can be cleaned up more. I just don't have the time to in the foreseeable future, sorry. I tackled #4 a bit, gave a high level overview in docs/testing.md and added docstrings to functions. |
bdbb755
to
1c35c96
Compare
OSX is now being tested. Updated .travis.yml file to manually install leiningen, worked out of the box. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could add [email protected]
as well.
cf https://github.com/orgs/LightTable/people
1c35c96
to
a9f0be0
Compare
a9f0be0
to
8fb6fc3
Compare
@lighttable/maintainers can one of you review this PR? |
Due to the large number of changes, and my lack of familiarity with the topic, I will be deferring to the other maintainers for this review. |
|
||
;Defines temporary directory for testing light table | ||
(def temp-home-directory | ||
(str (Files/createTempDirectory "lightable_homedir_for_testing" (into-array FileAttribute [])))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lighttable_homedir_for_testing
?
@@ -0,0 +1,34 @@ | |||
(ns lt.plugins.lighttable-test-plugin | |||
"Mocks & extends light table components for auotmated testing." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
automated
(defn show-file-dialog-mock | ||
"Mocks show-file-dialog so native file dialog does not show. | ||
A popup dialog with a text field is shown instead. File paths | ||
can be specified in the path fields, seperated by commas to donate |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
separated
Is there a need for system-level tests on macOS, Linux, and windows? I can update the PR if needed. |
@justintaft sure! if you have the time. This looks good, by my changes(in local) need to be somewhat modified after looking at this. |
DO NOT MERGE. EXPERIMENTAL.Whenever light table runs remote debugging is available. This is a security concern and we may want to change this in the future...
LightTable/deploy/core/main.js
Line 107 in baa2037
To access remote debugging tools:
To debug with web driver:
Sometimes light table does not initialize all the way. If this happens, close light table & retry.
I would like the system tests to use a cljs or js library, so we don't have to boot up the jvm for testing. Any Thoughts?