I also don't see any references to the Network selection screen.

Assigning to alemate@ who worked on the transformation of OOBE to Material Design

Do you know why that references to that button are missing? 
Or can you provide me with IDs for this "Let's Go" button and the "Next ->" button on the network selection screen

+others too if they have input on a better way to do this 

Friendly ping on this one :) 

This dialog is actually a real Gaia (online) page loaded in a webview.
webview is specifically isolated, I don't think you can inject any fake events in it using pure JS.

On the ChromeOS side we have test that can interact with real Gaia. See third_party/autotest/files/client/site_tests/login_* .

login_GaiaLogin will skip the screens of OOBE and go straight to the login screen and into logged-in ChromeOS though. I don't see much else in that test about interacting with the webview.

login_oobelocalization appears to read the OOBE language selection boxes on the at this line. 
https://cs.corp.google.com/chromeos_public/src/third_party/autotest/files/client/site_tests/login_OobeLocalization/login_OobeLocalization.py?type=cs&q=login_oobe&sq=package:%5Echromeos_(internal%7Cpublic)$&l=277

So it appears that it is reading from the webview with regular JS? 

Ah, actually I misunderstood you. Sorry.

Yes, you can definitely click on "Continue" button.
It is in shadow DOM, let me find how to do it...

This JS works:

$('oobe-welcome-md').$.welcomeScreen.$.welcomeNextButton.click()

Thank you!! The shadow DOM was what I needed to hear

There is no jquery in autotest but I was able to make it work with this:
document.getElementById("oobe-welcome-md").shadowRoot.getElementById("welcomeScreen").shadowRoot.getElementById("welcomeNextButton").click()

$ is not part of jquery . It is defined in ui/webui/resources/js/util.js , and this is the correct way of querying OOBE/Login/Lock elements.

I mean "the first $ is defined in ui/webui/resources/js/util.js", others are part of Polymer bindings, and are also the correct way of finding Polymer elements.

In general, we avoid writing tests that depend on the DOM of the oobe because someone can easily change the name of some element and your autotest will fail 3 days later. It's better to embed some test JS in the oobe that clicks through to the next screen.

Could you describe your test in some more detail? I'm not intimately familiar with the details of forced autoupdate.

alemate@:
You are correct. I tried and I am able to get to the Update check screen using these commands:
"$('oobe-welcome-md').$.welcomeScreen.$.welcomeNextButton.click()
"$('oobe-welcome-md').$.networkSelectionScreen.querySelector('oobe-next-button').click()
$('accept-button').click()

Thanks for the explanation. I learned something new! 

achuith@:
Yes a JS test function to jump to the screen I want to test would be awesome. 
I need to jump to the update check screen. Currently I am walking through the screens in this order: Welcome Screen, Network Selection, Terms & Conditions, Update Check Screen 

Here are the test details: 
At the OOBE update screen, ChromeOS does an update check to the update server defined by CHROMEOS_AUSERVER in /etc/lsb-release. If that update check returns a response that says there is an update available AND it contains a Deadline:Now parameter we will force the update at OOBE. Otherwise we will finish OOBE and do the update in the background. 

So the test will:
-Clear stateful to get back to OOBE
-Change CHROMEOS_AUSERVER to point to a devserver locally
-Step through (or jump) to Update Screen 
-Check that update completes successfully (additionally we can extend to do things like reboot in the middle) 
-Check that we are on the sign in screen at the end and the correct ChromeOS version

 Issue 790015  covers the request to jump to the network screen.

I'll take this bug back to cover the implementation of the test. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/autotest/+/004dc0393b769da43ddefbb690aa9736c988cae9

commit 004dc0393b769da43ddefbb690aa9736c988cae9
Author: David Haddock <dhaddock@chromium.org>
Date: Wed Dec 06 04:22:46 2017

Add OmahaDevserver back to autotest libraries.

This Class was in use with autoupdate_EndToEndTest for years. It was
removed when that test was moved to the devserver-on-dut model. Regular
update tests can use the local devserver model.

However, for updating at OOBE we need a devserver instance that can
survive a DUT reboot because:
1. This update reboots in the middle without user intervention
2. we will want to extend this test to reboot in the middle of the update
and verify that it continues. (We never want users to be able to skip forced
update).

We cannot use exisitng lab devservers because we need devservers with two
extra flags: --critical_update and --host_log. The first ensures that
deadline:now is set in the omaha response which trigger forced update.
The second ensure we have update events to parse and verify. These two flags
are not used to start lab devservers.

BUG= chromium:782828 
TEST=None

Change-Id: I3308d3b1c060d45262de4106fa8ded27461a603f
Reviewed-on: https://chromium-review.googlesource.com/805054
Commit-Ready: David Haddock <dhaddock@chromium.org>
Tested-by: David Haddock <dhaddock@chromium.org>
Reviewed-by: David Haddock <dhaddock@chromium.org>

[add] https://crrev.com/004dc0393b769da43ddefbb690aa9736c988cae9/server/cros/update_engine/omaha_devserver.py

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/2061b6652368f088fe705ecc5c9e2fff69543a9f

commit 2061b6652368f088fe705ecc5c9e2fff69543a9f
Author: David Haddock <dhaddock@chromium.org>
Date: Thu Dec 07 10:24:44 2017

Add autoupdate_ForcedOOBEUpdate to ebuild.

CQ-DEPEND=CL:804602
BUG= chromium:782828 
TEST=None

Change-Id: I904dd356b9c912a03f895dce9784e168520c1354
Reviewed-on: https://chromium-review.googlesource.com/810050
Commit-Ready: David Haddock <dhaddock@chromium.org>
Tested-by: David Haddock <dhaddock@chromium.org>
Reviewed-by: David Haddock <dhaddock@chromium.org>

[modify] https://crrev.com/2061b6652368f088fe705ecc5c9e2fff69543a9f/chromeos-base/autotest-server-tests/autotest-server-tests-9999.ebuild

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/autotest/+/95e7fbefaaee5ca739ab30d0db05ce5969ded5c7

commit 95e7fbefaaee5ca739ab30d0db05ce5969ded5c7
Author: David Haddock <dhaddock@chromium.org>
Date: Thu Dec 07 10:24:43 2017

[autotest] Add a test for forced update at OOBE.

We want to automatically test the first update experience for many
users at OOBE. This CL adds a client test to start the update and a server
test to verify that update completes successfully.

The test gets a payload to use from the job_repo_url. This will give us
a payload for updating to the build that we are currently running
(N->N). This is because most of time this test runs it will be on a ToT
build.

Updates at OOBE are forced only when the 'deadline' option exists in the
omaha response. We will start a devserver with the --critical_update
flag to do this.

We create a custom lsb-release file to override the default. This will
tell update_engine to ping our custom devserver at OOBE.

The test will later be expanded to reboot in the middle, sleep, kill
network etc. So we could not have the devserver it communicates with be
on the DUT.

BUG= chromium:782828 
TEST=test_that <ip> autoupdate_ForcedOOBEUpdate

Change-Id: Ifee5c9389320e8baf4a8998649de18abc182050d
Reviewed-on: https://chromium-review.googlesource.com/804602
Commit-Ready: David Haddock <dhaddock@chromium.org>
Tested-by: David Haddock <dhaddock@chromium.org>
Reviewed-by: Amin Hassani <ahassani@chromium.org>

[add] https://crrev.com/95e7fbefaaee5ca739ab30d0db05ce5969ded5c7/client/site_tests/autoupdate_StartOOBEUpdate/autoupdate_StartOOBEUpdate.py
[add] https://crrev.com/95e7fbefaaee5ca739ab30d0db05ce5969ded5c7/client/site_tests/autoupdate_StartOOBEUpdate/control
[add] https://crrev.com/95e7fbefaaee5ca739ab30d0db05ce5969ded5c7/server/site_tests/autoupdate_ForcedOOBEUpdate/autoupdate_ForcedOOBEUpdate.py
[add] https://crrev.com/95e7fbefaaee5ca739ab30d0db05ce5969ded5c7/server/site_tests/autoupdate_ForcedOOBEUpdate/control

The devserver directory provided by the drones does not match the path on the devserver. Its a quick fix

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/autotest/+/a49c9e83368160b14bf6aabb4863c9cfad964b4f

commit a49c9e83368160b14bf6aabb4863c9cfad964b4f
Author: David Haddock <dhaddock@chromium.org>
Date: Fri Dec 08 03:07:34 2017

Fix devserver directory.

The devserver_dir listed in the drones global_config.ini does not match the
path on the devservers. This CL will just change the devserver_dir to
match.

BUG= chromium:782828 
TEST=None

Change-Id: I040d1b94e6ab4960c0e71ad1f1d931032da5abfc
Reviewed-on: https://chromium-review.googlesource.com/815952
Reviewed-by: David Haddock <dhaddock@chromium.org>
Commit-Queue: David Haddock <dhaddock@chromium.org>
Tested-by: David Haddock <dhaddock@chromium.org>
Trybot-Ready: David Haddock <dhaddock@chromium.org>

[modify] https://crrev.com/a49c9e83368160b14bf6aabb4863c9cfad964b4f/server/cros/update_engine/omaha_devserver.py

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/d2bc6a94c80f3f5646a80c045ec5b14549e22e2f

commit d2bc6a94c80f3f5646a80c045ec5b14549e22e2f
Author: David Haddock <dhaddock@chromium.org>
Date: Sun Dec 10 00:03:30 2017

Add autoupdate_StartOOBEUpdate to autotest-chrome-9999.ebuild.

Forgot to add it and the main autotest is failing.

BUG= chromium:782828 
TEST=None

Change-Id: I264e36935767ad08ab45b2dd19b1fd7e285c2198
Reviewed-on: https://chromium-review.googlesource.com/817367
Commit-Ready: David Haddock <dhaddock@chromium.org>
Tested-by: David Haddock <dhaddock@chromium.org>
Reviewed-by: David Haddock <dhaddock@chromium.org>

[modify] https://crrev.com/d2bc6a94c80f3f5646a80c045ec5b14549e22e2f/chromeos-base/autotest-chrome/autotest-chrome-9999.ebuild

Now mostly passing. I will follow up with fixes in a separate bug.