This change makes all remaining tests use test.py's test_controller.js:
We have our own way of testing using test.py and that might change any time.
It's therefore not wise to rely on functionality in the unittest framework. If
we kept test_controller.js in the unittest package, we'd need to make a breaking
change whenever we change the behavior of test_controller.js. So this file was
forked into tools/testing/dart/test_controller.js.
After this, all our tests will use tools/testing/dart/test_controller.js. It is
therefore no longer necessary for the browser_controller to support the old
mechanism of posting back results. By removing this legacy code, we can ensure,
that the driving page of browser_controller will only react on valid messages
which were ment for it.
Context:
Some tests (e.g. dromaeo) might use postMessage internally, maybe even for
testing that postMessage is working. But the driving window should only react
on valid messages ment for it, ignoring any other messages.
R=blois@google.com, efortuna@google.com, ricow@google.com, whesse@google.com
Review URL: https://codereview.chromium.org//177333004
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@33365 260f80e4-7a28-3924-810f-c04153c831b5
This script supports two commands:
deflake:
This command will go through all status file entries and check if the actual
testoutcomes we've observed on our buildbots match the status file entries.
If we have tests marked as flaky which are in fact not flaky, it will write
a *.status.deflaked file which contains the fixes to the status file.
fix:
This command will go through all status files and ensures that all the
status file lines correspond to existing tests.
If we have lines that refer to non-existent tests, it will write a
*.status.fixed file which contains the fixes to the status file.
R=whesse@google.com
Review URL: https://codereview.chromium.org//143453012
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@32694 260f80e4-7a28-3924-810f-c04153c831b5
"package/" under the web/ directory. Resolution under 'lib' is the same, but it and gives better suggestions if the path looks wrong. This summarizes what changed:
- source file: lib/b.html
import to "packages/c/d.html" was error, now is error + suggestion
import to "../packages/c/d.html" was error, now is error + suggestion
import to "../../packages/c/d.html" was resolved, now is resolved too
- source file: lib/a/b.html
import to "packages/c/d.html" was error, now is error + suggestion
import to "../packages/c/d.html" was error, now is error + suggestion
import to "../../packages/c/d.html" was error, now is error + suggestion
import to "../../../packages/c/d.html" was resolved, now is resolved too
- source file: web/b.html
import to "packages/c/d.html" was and continues to be resolved
import to "../packages/c/d.html" was error, now is resolved
- source file: web/a/b.html
import to "packages/c/d.html" was error, now is resolved
import to "../packages/c/d.html" was and continues to be resolved
import to "../../packages/c/d.html" was and continues to be resolved
Note: polymer-build and development mode are slightly different: polymer-build
detects and issues an error for bad paths inside lib/. These are not detected by
our package-resolution in loader.dart, but as long as users are not creating
symlinks by hand, Dartium should detect if the paths are wrong.
When we switch to start using pub-serve by default, we should be able to go back
to the web-ui style of using "package:" urls directly in HTML.
R=jmesserly@google.com, kustermann@google.com
Review URL: https://codereview.chromium.org//148913003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@32170 260f80e4-7a28-3924-810f-c04153c831b5
This will be used on the bots to be able to archive dumps from unexpectec crashes.
The tools/archive_crash.py tool will be used to actually archive the dumps to gcs and delete the local copies. The reason for the split is to enable developers to actually utilize this locally as well (run tools/test.py in a loop but don't archive the expected crashes). Additionally, this puts the bot specific code in the small python script.
R=whesse@google.com
Review URL: https://codereview.chromium.org//145273024
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@32111 260f80e4-7a28-3924-810f-c04153c831b5
For all tests that depend on other packages (e.g. samples) we can
- use packages from pub.dartlang.org
- use packages from pub.dartlang.org with overrides for the packages we have
in the dart repository.
This CL does NOT include test-specific package-roots for dartium. Dartium will request a URL containing
"packages" when it encounters a package import. Our HTTP server will then serve from buildDir/packages.
This needs to change when we have test specific VMOptions for dartium.
For normal tests (without a pubspec.yaml on the path to dart/, we still use buildDir/packages).
R=ricow@google.com, whesse@google.com
Review URL: https://codereview.chromium.org//126173002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@31691 260f80e4-7a28-3924-810f-c04153c831b5
This CL adds
- support for fetching dependencies via 'pub get' of samples/packages
- support for building applications/samples via 'pub build' (or a custom
build.dart file)
- pkg/pkgbuild.status: Status files for all package checkouts/builds
- the '--use-public-packages' option to test.dart
- the CleanDirectoryCopyCommand, PubCommand, ModifyPubspecYamlCommand commands
The test suite can be executed with:
$ ./tools/test.py -mrelease --use-sdk pkgbuild
$ ./tools/test.py -mrelease --use-sdk --use-public-packages pkgbuild
R=ricow@google.com
Review URL: https://codereview.chromium.org//122443003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@31535 260f80e4-7a28-3924-810f-c04153c831b5
efortuna@google.com