-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Improving the dev workflow: Setup browserstack, add necessary configuration files and tests for mobile #5340
Conversation
…stack-integration
@@ -0,0 +1,2 @@ | |||
USERNAME={Browserstack username} |
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.
what's this? is it needed? probably needs some explanation on the process for using the actual credentials...
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.
This is the sample environment file. An similar file named .browserstack.env
with the actual credentials is required to run the tests locally on Browserstack. I will add some explanation for this. Thanks!
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.
Oh ok. But the tests are going to run on Travis too, right?
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.
Yes, they will continue to run as they now. I have also shared a doc with you regarding the plan.
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.
Hi @apb7 , I have been looking at this PR for a while now. Would it be possible for me to take a look at this doc as well?
Codecov Report
@@ Coverage Diff @@
## develop #5340 +/- ##
===========================================
- Coverage 47.3% 47.29% -0.01%
===========================================
Files 496 496
Lines 28436 28442 +6
Branches 4343 4344 +1
===========================================
Hits 13452 13452
- Misses 14984 14990 +6
Continue to review full report at Codecov.
|
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.
Hi @apb7, left some comments, ptal!
// Code to start browserstack local before start of test | ||
beforeLaunch: function(){ | ||
// eslint-disable-next-line no-console | ||
console.log('Connecting local'); |
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.
Connecting browserstack local
// This can be changed via the command line as: | ||
// --params.login.user 'Joe' | ||
params: { | ||
login: { |
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.
Do we need this?
// ----- Options to be passed to mocha ----- | ||
// | ||
// See the full list at http://visionmedia.github.io/mocha/ | ||
mochaOpts: { |
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.
Can we remove this?
}, | ||
|
||
// ----- Options to be passed to cucumber ----- | ||
cucumberOpts: { |
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.
And this?
…, in LibraryPage object
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.
Seems better on first glance but grepping for browser.isMobile uncovered a couple more things. Once you fix them I'll do a full review.
Thanks!
core/tests/protractor/libraryFlow.js
Outdated
|
||
var rateExploration = function() { | ||
if (browser.isMobile) { | ||
var adminPage = new AdminPage.AdminPage(); |
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.
This stuff doesn't look like a single line
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.
Here we use a different function to login for the mobile: users.createAndLoginAdminUserMobile. Therefore, the difference in lines. We can however use the same function for desktop too. How should we go about this then? Shall we rename it to something like: createAndLoginAdminUserViaAdminCheckboxOnly or something on that lines?
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.
I guess I don't understand why the user is admin in one case and non-admin in the other case, or why the usernames and email addresses used are different. Can we make them the same? Ideally you would not need any branching at all except for reloadExploration() vs createAndPublishExploration().
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.
Okay, so we can have a single admin user and then reload or create and publish the exploration but we should use users.createAndLoginAdminUserMobile function instead of users.createAndLoginAdminUser to prevent any popups of the admin page and rename the function appropriately. Does that sounds good? Thanks!
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.
So, I didn't actually understand the comment in the code. What popup exactly is appearing?
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.
OK. For clarity, think of the admin page as the "superadmin page".
I get that, on mobile, stuff is loaded from the superadmin page. But I think you solved that in all the other tests already quite cleanly, so I'm not sure why this test is special in that regard...?
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.
Okay, understood. This was the approach I had adopted:
users.createUser('random@gmail.com', 'random');
users.login('random@gmail.com', true);
if (browser.isMobile) {
var adminPage = new AdminPage.AdminPage();
adminPage.reloadExploration('protractor_mobile_test_exploration.yaml');
} else {
workflow.createAndPublishExploration(
EXPLORATION_TITLE,
EXPLORATION_CATEGORY,
EXPLORATION_OBJECTIVE,
EXPLORATION_LANGUAGE
);
}
...
...
users.logout();
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.
This seems reasonable :) Try to get the stuff within each branch to a single call, though.
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.
Sounds good. I will move the admin page initialisation to outside the branching so as to reduce this to a single call. Thanks :)
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.
Done, thanks!
searchInput.sendKeys(explorationTitle); | ||
// The library page has two search bar input elements. | ||
|
||
if (browser.isMobile) { |
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.
Should not duplicate so much code with findCollection(). Have both methods delegate to an internal method for selectLibraryTile(tileName) perhaps.
Actually the name is ambiguous. Looks like it's just entering input in search bar, does it hit enter? Maybe submitSearchQuery() would be better.
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.
Created a separate function, _submitSearchQuery(searchQuery)
for this and moved the duplicate code under it and then called it appropriately. Done, thanks!
@seanlip: I have addressed both the review comments. Can you please take another look? Thanks! |
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.
Almost there!
@@ -0,0 +1,58 @@ | |||
// Copyright 2018 The Oppia Authors. All Rights Reserved. |
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.
Hm. Did this get removed in develop? Surprised to see it here -- might want to check. /cc @bansalnitish
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.
Yup, it's removed.
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.
Whoops! Removed this. Thanks!
core/tests/protractor/learnerFlow.js
Outdated
libraryPage = new LibraryPage.LibraryPage(); | ||
learnerDashboardPage = new LearnerDashboardPage.LearnerDashboardPage(); | ||
|
||
if (browser.isMobile) { |
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.
In all such if/else statements, both branches should have the same functionality. This isn't the case here.
It might be better to do the branching on a per-test basis.
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.
Done, followed the per-test basis. Thanks!
core/tests/protractor/learnerFlow.js
Outdated
|
||
it('visits the exploration player and plays the correct exploration', | ||
function() { | ||
if (!browser.isMobile) { |
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.
Should have corresponding branch for mobile that is clearly equivalent to desktop branch.
Ditto in all other tests in this file. Ditto in other files if applicable.
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.
Done, the per-test basis resolved this. Thanks!
core/tests/protractor/learnerFlow.js
Outdated
afterEach(function() { | ||
if (browser.isMobile) { | ||
general.checkForConsoleErrors([ | ||
// TODO(apb7): Remove these when https://github.com/oppia/oppia/issues/5363 is resolved. |
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.
OK -- we really need to find a way around this. The console error log is getting a bit ridiculous...
These error logs are generated by us. (Search for "SearchQuery" in the codebase.) What are the exact values of $('.oppia-search-bar-input').val().trim() and searchQuery, respectively? We should be able to get more insight than what's currently in #5363.
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.
Okay, so the problem here was, we have two oppia-search-bar-input
tags -- the first one is visible for desktop and the second one is visible for mobile devices. $('.oppia-search-bar-input').val().trim()
takes into consideration only the first search bar input tag which, in case of mobile, has no value since the mobile devices use the second search bar input tag and therefore, the searchQuery does not match and we get the console errors. I think this also conveys that this error must have been introduced in the PR stage only, that is, in PR #4807, contrary to our belief that it was introduced by some later update.
I have fixed this error by checking all search bar input tags and throwing the console error if the value of none of them match the searchQuery. This fixes the issue. Thanks!
core/tests/protractor/loginFlow.js
Outdated
var users = require('../protractor_utils/users.js'); | ||
var waitFor = require('../protractor_utils/waitFor.js'); | ||
|
||
describe('Login flow', function() { |
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.
Looks more like a test for the profile dropdown menu to me...
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.
We have another nested describe
block for profile dropdown menu here.
Do we still need to change this description?
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.
Could we rename it (and the file) to something like "navigation" perhaps? This file is, like, 90% non-login stuff, so the name seems misleading.
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.
Yes, I agree. Since we already have a file named navigation for mobile, shall I change this to profileFlow since it's mostly concerned about navigation using the profile menu?
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.
profileMenuFlow perhaps? But otherwise sgtm.
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.
Done, renamed to profileMenuFlow. Thanks!
var reloadCollectionButtons = element.all(by.css( | ||
'.protractor-test-reload-collection-button')); | ||
|
||
var explorationTitleElement = function(explorationElement) { |
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.
Start functions with get
. Ditto for explorationElementReloadButton.
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.
Done, thanks!
// page is rendered for mobile device. | ||
|
||
// get function is a zero-based index. | ||
var mobileSearchInput = searchInputs.get(1); |
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.
Reduce branching:
// ...
var searchInput = (browser.isMobile ? searchInputs.get(1) : searchInputs.first());
searchInput.clear();
searchInput.sendKeys(searchQuery);
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.
Done, thanks!
…stack-integration
@seanlip: I have addressed all review comments. Can you please take another look? Thanks! |
core/tests/protractor/learnerFlow.js
Outdated
@@ -403,9 +399,13 @@ describe('Learner dashboard functionality', function() { | |||
// 'Test Collection'. |
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.
Why is this test only for desktop? Mobile and desktop should test the same functionality.
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.
Okay, let me once state what this part of the test does. We go to the creator dashboard and then navigate to the collection editor page by clicking on the "Collections" tab. We then chose a collection and then we chose an exploration to add to the existing collection.
It is only for desktop because of the following reasons:
- A user can only add an existing exploration to a collection he has created. For desktop, the user creates a collection. Later on, it adds to the same collection it had created earlier. But for mobile, we load a collection and not create it. Therefore, the user cannot add an existing exploration to the loaded collection since the collection is predefined.
- This involves the collection editor page, which I think has certain components which are not mobile friendly.
- Creating and later on, editing a collection involves an admin user and not a super admin. We sign-in as super admin for mobile.
- Also, the collection editor page where we add an existing exploration says that its in beta. So I am not too sure how it will be affected in case of mobile devices.
Therefore, this part was kept under desktop.
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.
OK, thanks for explaining. Should we keep this part in protractor_desktop then (and add comments explaining why)?
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.
(I think in general stuff in protractor/ is stuff that gets tested on both mobile and desktop.)
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.
Actually this is just a part of the same test -- it checks the same functionality, that is, after adding an existing exploration to the collection which was earlier completed, the collection now appears under the incomplete collection section. Therefore, I think we can keep it here and add the explanation as to why it is a desktop only thing. Also, if we place this in a separate file, it would again require the same setup -- creating two explorations and a collection and then testing this. Shall we add the explanation here only?
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.
OK, yep that's fine.
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.
All good, just one more thing!
@seanlip: Please take another look :) Thanks! |
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.
LGTM. Thanks!
Thanks, Sean :) |
Merging this, thanks! |
Explanation
Fixes #2991 and Fixes #5363
Checklist
python scripts/pre_commit_linter.py
andbash scripts/run_frontend_tests.sh
.