Skip to content
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

Merged
merged 108 commits into from
Aug 4, 2018

Conversation

apb7
Copy link
Contributor

@apb7 apb7 commented Jul 20, 2018

Explanation

Fixes #2991 and Fixes #5363

Checklist

  • The PR title starts with "Fix #bugnum: ", followed by a short, clear summary of the changes.
  • The PR explanation includes the words "Fixes #bugnum: ...".
  • The linter/Karma presubmit checks have passed.
    • These should run automatically, but if not, you can manually trigger them locally using python scripts/pre_commit_linter.py and bash scripts/run_frontend_tests.sh.
  • The PR is made from a branch that's not called "develop".
  • The PR follows the style guide.
  • The PR is assigned to an appropriate reviewer.
    • If you're a new contributor, please ask on Gitter for someone to assign a reviewer.
    • If you're not sure who the appropriate reviewer is, please assign to the issue's "owner" -- see the "talk-to" label on the issue.

@apb7 apb7 requested a review from kevinlee12 July 20, 2018 19:53
@@ -0,0 +1,2 @@
USERNAME={Browserstack username}
Copy link
Member

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...

Copy link
Contributor Author

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!

Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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-io
Copy link

codecov-io commented Jul 21, 2018

Codecov Report

Merging #5340 into develop will decrease coverage by <.01%.
The diff coverage is 32%.

Impacted file tree graph

@@             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
Impacted Files Coverage Δ
...tes/dev/head/components/SolutionEditorDirective.js 12.5% <0%> (ø) ⬆️
...ts/summary_tile/ExplorationSummaryTileDirective.js 1.53% <0%> (ø) ⬆️
...oration_editor/statistics_tab/PieChartDirective.js 6.25% <0%> (ø) ⬆️
...tion_editor/ExplorationObjectiveEditorDirective.js 20% <0%> (ø) ⬆️
...v/head/pages/learner_dashboard/LearnerDashboard.js 2.27% <0%> (ø) ⬆️
...dev/head/services/SpeechSynthesisChunkerService.js 23.28% <0%> (ø) ⬆️
core/templates/dev/head/pages/library/Library.js 24.34% <0%> (ø) ⬆️
...nts/summary_tile/CollectionSummaryTileDirective.js 14.28% <0%> (ø) ⬆️
core/templates/dev/head/services/SearchService.js 38.05% <0%> (-2.14%) ⬇️
...itor/editor_tab/SkillConceptCardEditorDirective.js 1.61% <0%> (ø) ⬆️
... and 5 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a9080d4...4e14f53. Read the comment docs.

Copy link
Contributor

@kevinlee12 kevinlee12 left a 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');
Copy link
Contributor

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: {
Copy link
Contributor

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: {
Copy link
Contributor

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: {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And this?

@apb7 apb7 changed the title Improving the dev workflow: Setup browserstack and necessary configuration files [WIP] Improving the dev workflow: Setup browserstack and necessary configuration files Jul 21, 2018
Copy link
Member

@seanlip seanlip left a 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!


var rateExploration = function() {
if (browser.isMobile) {
var adminPage = new AdminPage.AdminPage();
Copy link
Member

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

Copy link
Contributor Author

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?

Copy link
Member

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().

Copy link
Contributor Author

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!

Copy link
Member

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?

Copy link
Member

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...?

Copy link
Contributor Author

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();

Copy link
Member

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.

Copy link
Contributor Author

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 :)

Copy link
Contributor Author

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) {
Copy link
Member

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.

Copy link
Contributor Author

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!

@oppiabot
Copy link

oppiabot bot commented Aug 3, 2018

Hi @apb7. Due to recent changes in the "develop" branch, this PR now has a merge conflict. Please follow this link if you need help resolving the conflict, so that the PR can be merged. Thanks!

@apb7
Copy link
Contributor Author

apb7 commented Aug 3, 2018

@seanlip: I have addressed both the review comments. Can you please take another look? Thanks!

Copy link
Member

@seanlip seanlip left a 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.
Copy link
Member

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, it's removed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whoops! Removed this. Thanks!

libraryPage = new LibraryPage.LibraryPage();
learnerDashboardPage = new LearnerDashboardPage.LearnerDashboardPage();

if (browser.isMobile) {
Copy link
Member

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.

Copy link
Contributor Author

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!


it('visits the exploration player and plays the correct exploration',
function() {
if (!browser.isMobile) {
Copy link
Member

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.

Copy link
Contributor Author

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!

afterEach(function() {
if (browser.isMobile) {
general.checkForConsoleErrors([
// TODO(apb7): Remove these when https://github.com/oppia/oppia/issues/5363 is resolved.
Copy link
Member

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.

Copy link
Contributor Author

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!

var users = require('../protractor_utils/users.js');
var waitFor = require('../protractor_utils/waitFor.js');

describe('Login flow', function() {
Copy link
Member

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...

Copy link
Contributor Author

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?

Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Member

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.

Copy link
Contributor Author

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) {
Copy link
Member

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.

Copy link
Contributor Author

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);
Copy link
Member

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);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done, thanks!

@apb7
Copy link
Contributor Author

apb7 commented Aug 3, 2018

@seanlip: I have addressed all review comments. Can you please take another look? Thanks!

@@ -403,9 +399,13 @@ describe('Learner dashboard functionality', function() {
// 'Test Collection'.
Copy link
Member

@seanlip seanlip Aug 3, 2018

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.

Copy link
Contributor Author

@apb7 apb7 Aug 3, 2018

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:

  1. 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.
  2. This involves the collection editor page, which I think has certain components which are not mobile friendly.
  3. Creating and later on, editing a collection involves an admin user and not a super admin. We sign-in as super admin for mobile.
  4. 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.

Copy link
Member

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)?

Copy link
Member

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.)

Copy link
Contributor Author

@apb7 apb7 Aug 3, 2018

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?

Copy link
Member

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.

Copy link
Member

@seanlip seanlip left a 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!

@apb7
Copy link
Contributor Author

apb7 commented Aug 3, 2018

@seanlip: Please take another look :) Thanks!

Copy link
Member

@seanlip seanlip left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks!

@apb7
Copy link
Contributor Author

apb7 commented Aug 4, 2018

Thanks, Sean :)

@apb7
Copy link
Contributor Author

apb7 commented Aug 4, 2018

Merging this, thanks!

@apb7 apb7 merged commit 0b5692a into develop Aug 4, 2018
@apb7 apb7 deleted the browserstack-integration branch August 4, 2018 18:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
6 participants