-
-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tests for non legacy zim files #1049
Conversation
@Jaifroid I have drafted this PR to get opinions and discuss some points before proceeding
maybe a better structure or should I leave it as it is describe('Legacy Ray Charles test [XZ compression] ' + (mode === 'jquery' ? '[JQuery mode]' : mode === 'serviceworker' ? '[SW mode]' : ''), async function () {
describe('Load app', function () {
it('Load Kiwix JS and check title', async function () {
.......
});
});
describe('Switch to ' + mode + ' mode', function () {
it('Switch to ' + mode + ' mode', async function () {
........
});
});
describe('Load archive', function () {
it('Load legacy Ray Charles and check index contains specified article', async function () {
........
});
});
describe('Navigate to linked article', function () {
it('Navigate to "This Littlge Girl of Mine"', async function () {
.........
});
}); proposed implementation:- describe('Legacy Ray Charles test [XZ compression] ' + (mode === 'jquery' ? '[JQuery mode]' : mode === 'serviceworker' ? '[SW mode]' : ''), async function () {
it('Load Kiwix JS and check title', async function () {
.......
});
it('Switch to ' + mode + ' mode', async function () {
........
});
it('Load legacy Ray Charles and check index contains specified article', async function () {
........
});
it('Navigate to "This Littlge Girl of Mine"', async function () {
.........
});
}); |
@RG7279805 I agree we can organize the tests into appropriate folders, as you suggest. I have been building up these tests over some time, and I started with just one runner and just one test, and they have grown since, necessitating some organization. I indeed originally had the structure in your proposed implementation. Unfortunately, however, Selenium runs all the individual tests simultaneously if they are not wrapped in separate I'm aware that on Stack Exchange, many people advise that each Hence, after a LOT of experimentation, I was forced to use this slightly unwieldly structure. However, in the GitHub Actions logs, it makes for a nicely readable set of test results like below. Therefore, I think we are obliged to keep Feel free to experiment with a different structure if you think it is possible to organize it better.
|
I have been working all day on a PR that enabled remote testing on BrowserStack. It's now finished, and I've merged it. Unfortunately, this came at the same time as your draft PR. I have made quite a few changes to the Ray Charles spec test, so you will need to use the updated file on You will need to resolve the conflicts or else start again from current |
@Jaifroid thanks for the insight as you are suggesting i will try to look for a better approach if possible (tests issue) Also should i refactor the folders or do I leave that upto you? |
If you want to have a go at re-ordering the folders, please feel free. You should probably create a separate issue and a separate PR for that, and do that one first before you start work on this one. |
tests/chromium.e2e.runner.js
Outdated
@@ -20,3 +21,4 @@ async function loadChromiumDriver () { | |||
const driver_chrome = await loadChromiumDriver(); | |||
|
|||
legacyRayCharles.runTests(driver_chrome); | |||
nonLegacyZim.runTests(driver_chrome); |
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.
Just a quick comment on why this doesn't work. You can't use the same driver instance, because it will be quit before the second test suite is run. You need to make a new instance, e.g. const driver_chrome_test2 = await loadChromiumDriver();
.
Hi @Jaifroid, describe('Legacy Ray Charles test [XZ compression] ' + (mode === 'jquery' ? '[JQuery mode]' : mode === 'serviceworker' ? '[SW mode]' : ''), async function () {
it('Load Kiwix JS and check title', async function () {
.......
});
it('Switch to ' + mode + ' mode', async function () {
........
});
it('Load legacy Ray Charles and check index contains specified article', async function () {
........
});
it('Navigate to "This Littlge Girl of Mine"', async function () {
.........
});
}); Output: Reset app
✔ Click the app reset button and accept warning
Legacy Ray Charles test [XZ compression] [JQuery mode]
✔ Load Kiwix JS and check title
✔ Switch to jquery mode
✔ Load legacy Ray Charles and check index contains specified article
✔ Navigate to "This Littlge Girl of Mine"
✔ Search for Ray Charles in title index and go to article
Legacy Ray Charles test [XZ compression] [SW mode]
✔ Load Kiwix JS and check title
✔ Switch to serviceworker mode
✔ Load legacy Ray Charles and check index contains specified article
✔ Navigate to "This Littlge Girl of Mine"
✔ Search for Ray Charles in title index and go to article
11 passing (17s)
|
Of course I remember -- we were in touch only yesterday! It's best to discuss these issues here on GitHub. I'm not sure why I was having issues with tests running simultaneously. Maybe it was with a slightly different structure, or maybe I was calling the individual tests asynchronously. I'm afraid I can't remember. If you've found a solution that ensures they run sequentially and simplifies them, then that's great 😊 |
I suggest that before you undertake much more work on this PR, you could do the other PR we mentioned above, which is about organizing the folder structure. |
One clarification on this part I was thinking to send this message on Slack but then didn't so I copied that message that's why it seems unusual
Sure, BTW I am nearly done with all tests as soon as this PR gets merged i will start working above issue (or should i leave current tests and fix folder structure first?) |
I thought it might be easier for you to work on the other one first, as it would give you some experience with the way the tests work, the way imports work, etc. But either order is fine by me. It's really up to you. By the way, I think you should give your new test spec a more meaningful name. I would recommend something like Please also note that I have now made the "Reset App" part of the test run only when the test is local, i.e. when it is not running in CI. Take a look at the latest code in the legacy test to see how to run only on local. We don't need to reset the app when running in GitHub actions because it is always running as a freshly built app in a virgin environment. Bypassing it speeds up the tests. Given the changes I made, including adding some retries, you'll need to incorporate these into the new test as well as the legacy test. That's why it might be easier to do the other PR first, and then start this one again from the latest files. I won't be working more on tests, having just fixed the last issue (for now) I had identified with them. |
But as I wrote, the order you do them in is completely up to you. |
[UPDATE]: It took me more time than expected to write all the tests initially I thought I finish them in 2 days
All the tests are done as mentioned below let me know if I missed something
|
That's wonderful, thank you! I notice the tests aren't actually running on each PR push. I'm not sure if that's because you've disabled them or because of the conflicts that need to be resolved. Remember that you're working off an old copy of legacy-ray_charles, so you need to get the new one and apply the changes you made manually to it. Also, remember that clicking the app reset button should be in the test, but it is wrapped so that it won't run during CI. It's only needed when a dev is testing locally. The code in the latest version of You won't be able to do some of those actions you list in jQuery mode, because it doesn't run dynamic scripts in the ZIM. So some of the tests won't be relevant in that mode. However, you can still navigate to a book cover using the title search and still view the HTML and download the epub. Downloading the epub and testing that it has downloaded might be a bit challenging, so it can be optional. Or maybe you worked it out already? |
Yes it was annoying to run every test for legacy Zim and then run the actual code i am writing
aye aye sir
I have found a way to check that on chrome and Firefox |
Kudos! |
- Base Tests - Load archive - Extra buttons and Language Dropdown
- Download EPUB file - Search books and Results
- Active content warning - Viewing article HTML view - Download File and check - exporting paths from single file
- Page Navigation - Viewing HTML page content
Thank you that meant a lot but I did take a lot of time
For now I am using the node's native By the way, regarding my PR, you might have noticed several missing semicolons. Do you believe the project could gain from using Prettier? I would be happy to make a PR after |
@RG7279805 If you're using Node's native FS module, I wonder if you need to import it explicitly. Where I use native FS in Kiwix JS Windows (for Electron), I have to do something like:
(That's probably not quite right, because in fact I have to use CommonJS module, with |
But obviously, if WebDriver provides FS methods, then it would be a better solution. |
By all means prettify your own file, but it's best not to prettify an entire project. Instead, I prefer to use ESLint and fix the files as I work on them. It's more flexible with the rules that can be defined. I probably just need to add a rule to enforce semicolon use, in which case your IDE will warn you more obviously. In any case, it's really minor, so don't worry about that for now! |
Just quickly to mention that I'm doing an Internationalization PR #1061, and it will have (is already having) small knock-on effects for e2e tests because some of our tests are checking language-specific UI for asserting that a change has happened. E.g., when we switch to jQuery mode, the legacy test looks for the text in the API panel that says that the SW API is not registered or is unavailable. We'll need to change this so that tests for such functions don't depend on the loaded language. E.g., for the mode switching, I'll change the test so that it looks instead for the class name |
@Jaifroid I have fixed the CI error issue finally 🤘. It wasn't a Filesystem problem rather the download button couldn't be clicked due to some reason (don't know why) so instead of calling
Understood, When can I expect the tests to be updated or maybe you can merge this PR and I will fix the tests again? |
This is excellent news! Well done! Yes, I sometimes found that I had to resort to doing things in JS because WebDriver would error out on it, saying it couldn't be done... (clicking elements in particular). My Internationalization PR won't be ready for a while yet because I'm trying to include at least one full translation of the app (into Spanish), and there are several more fiddly messages to convert. So it would be best for us to sqaush/merge your PR when you tell me it's ready. Could I check why you could not include the iemode.runner.js with your new spec test? Surely it would just run through the parts of the test that are valid in jquery mode, and leave it at that? The runner can also restrict the test to jquery mode also simply by passing the array There is one area you can't test in this PR because you don't have access to the Repo secrets. This is running tests on BrowserStack on older browsers. However, I think rewriting those runners could be a different PR. Especially if anything fails after we merge your PR and the full suite of tests are run. |
@Jaifroid There are 2 bugs in IE mode
tests in jquery mode are passing except for download .epub (passing since we can't check the actual downloaded file on Edge)
Sure, I will fix any problem I may have to learn a bit about Browser stack though |
OK, that sounds good. It seems the Gutenberg ZIMs are increasingly coded in a way that is no longer compatible with IE11 (inevitable, really). We don't care about IE11 for its own sake, because even users of Windows XP can download a compatible Chrome and use that instead, but it is a good proxy for other older systems we might not be able to test for. But in this case, it's clearly the ZIM that has "moved on", and we can't code anything much to compensate for that. So I agree, we should merge. I'll do a review in case there are any last small things to catch. |
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.
The code is looking great. I just have some minor mostly formatting comments for final tidying. Let me know when you've done these, and I think we'll be ready to squash/merge.
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.
Just some tiny last things!
@Jaifroid Can you merge this PR now? |
Many thanks once again for this PR. Great work and really useful for the project as a whole! About to merge. |
closes #1042
Sorry I messed up my commit history in my last PR so I am reopening this after fixing the issue nonetheless