Searched +refs:run +refs:many +refs:tests (Results 1 – 25 of 527) sorted by relevance
12345678910>>...22
| /external/grpc-grpc/tools/run_tests/ |
| D | README.md | 3 This directory contains scripts that facilitate building and running tests. We are using python scr…
4 tests because that gives us the opportunity to run tests using the same commandline regardless of t…
6 # Unit tests (run_tests.py)
8 Builds gRPC in given language and runs unit tests. Use `tools/run_tests/run_tests.py --help` for mo…
13 ###### Useful options (among many others)
14 …ontainer containing all the prerequisites for given language and runs the tests under that contain…
15 - `--build_only` Only build, do not run the tests.
19 Note: some tests may be flaky. Check the "Issues" tab for known flakes and other issues.
21 The full suite of unit tests will take many minutes to run.
23 # Interop tests (run_interop_tests.py)
[all …]
|
| /external/rust/crates/grpcio-sys/grpc/tools/run_tests/ |
| D | README.md | 3 This directory contains scripts that facilitate building and running tests. We are using python scr…
4 tests because that gives us the opportunity to run tests using the same commandline regardless of t…
6 # Unit tests (run_tests.py)
8 Builds gRPC in given language and runs unit tests. Use `tools/run_tests/run_tests.py --help` for mo…
13 ###### Useful options (among many others)
14 …ontainer containing all the prerequisites for given language and runs the tests under that contain…
15 - `--build_only` Only build, do not run the tests.
19 Note: some tests may be flaky. Check the "Issues" tab for known flakes and other issues.
21 The full suite of unit tests will take many minutes to run.
23 # Interop tests (run_interop_tests.py)
[all …]
|
| /external/zstd/tests/regression/ |
| D | README.md | 1 # Regression tests
3 The regression tests run zstd in many scenarios and ensures that the size of the compressed results…
5 These tests get run every night by CircleCI. If the job fails you can read the diff printed by the …
9 From the root of the zstd repo run:
17 cd tests/regression
|
| /external/wycheproof/ |
| D | README.md | 14 Project Wycheproof tests crypto libraries against known attacks. It is developed
18 At Google, we rely on many third party cryptographic software libraries.
28 of unit tests that detect known weaknesses or check for expected behaviors of
29 some cryptographic algorithm. Project Wycheproof provides tests for most
37 While we are committed to develop as many attacks as possible, Project
38 Wycheproof is by no means complete. Passing the tests does not imply that the
40 Project Wycheproof tests for. Cryptographers are also constantly discovering
50 Project Wycheproof has tests for the most popular crypto algorithms, including
62 The tests detect whether a library is vulnerable to many attacks, including
67 - And many more -- we have over 80 test cases
[all …]
|
| /external/pigweed/pw_unit_test/ |
| D | docs.rst | 11 ``pw_unit_test`` is a portable library which can run on almost any system from
14 communicating its results through a common interface. Unit tests can be written
15 once and run under many different environments, empowering developers to write
18 ``pw_unit_test`` is still under development and lacks many features expected in
26 Writing unit tests
48 As the framework runs tests, it calls the event handler's callback functions to
63 [==========] Running all tests.
80 [==========] Done running all tests.
87 .. _running-tests:
89 Running tests
[all …]
|
| /external/ltp/pan/cgi/ |
| D | README | 10 <host> The hostname the tests were run on
17 summary - a very brief table listing how many tests passed,
18 failed, didn't run, etc. This wasn't released.
33 to compare as many results as you want, side by side. Also, I started
46 before running the tests. I use this information to display the `uname
48 information, but the scripts should still run.
|
| /external/igt-gpu-tools/ |
| D | README.md | 8 drivers. There are many macro-level test suites that get used against the
10 those can be difficult to track down to kernel changes, and many require
12 results. Therefore, IGT GPU Tools includes low-level tools and tests
22 The benchmarks require KMS to be enabled. When run with an X Server
23 running, they must be run as root to avoid the authentication
26 Note that a few other microbenchmarks are in tests (like gem_gtt_speed).
28 **tests/**
30 This is a set of automated tests to run against the DRM to validate
31 changes. Many of the tests have subtests, which can be listed by using
32 the --list-subtests command line option and then run using the
[all …]
|
| D | NEWS | 32 dropping the audio tests that required exotic custom hardware to
42 And many other bug fixes, improvements, cleanups and new tests.
99 - kms_frontbuffer_tracking no longer tests sink crc. (Dhinakaran Pandiyan)
104 And many other bug fixes, improvements, cleanups and new tests.
129 - Moved handling of a "cork" BO into lib from various tests.
153 And many other bug fixes, improvements, cleanups and new tests.
212 And many other bug fixes, improvements, cleanups and new tests.
250 - Converted remaining shell-script tests to C code (Abdiel Janulgue)
252 - Multiple new tests.
255 And many other bug fixes and improvements.
[all …]
|
| /external/skia/site/docs/dev/testing/ |
| D | testing.md | 16 When you run this, you may notice your CPU peg to 100% for a while, then taper
17 off to 1 or 2 active cores as the run finishes. This is intentional. DM is very
19 forced to run on a single thread. You can use `--threads N` to limit DM to N
30 492 srcs * 3 sinks + 382 tests == 1858 tasks
54 supports many test configurations, which are not all appropriate for all
55 machines. These lines are a sort of FYI, mostly in case DM can't run some
56 configuration you might be expecting it to run.
65 492 srcs * 3 sinks + 382 tests == 1858 tasks
68 DM has found 382 unit tests (code linked in from tests/), and 492 other drawing
69 sources. These drawing sources may be GM integration tests (code linked in from
[all …]
|
| /external/skqp/site/dev/testing/ |
| D | testing.md | 14 When you run this, you may notice your CPU peg to 100% for a while, then taper
15 off to 1 or 2 active cores as the run finishes. This is intentional. DM is
17 still forced to run on a single thread. You can use `--threads N` to limit DM to
26 492 srcs * 3 sinks + 382 tests == 1858 tasks
49 supports many test configurations, which are not all appropriate for all
50 machines. These lines are a sort of FYI, mostly in case DM can't run some
51 configuration you might be expecting it to run.
59 492 srcs * 3 sinks + 382 tests == 1858 tasks
62 DM has found 382 unit tests (code linked in from tests/), and 492 other drawing
63 sources. These drawing sources may be GM integration tests (code linked in
[all …]
|
| /external/angle/doc/ |
| D | CaptureAndReplay.md | 7 * GLES capture has many unimplemented functions.
10 * Mid-execution capture has many unimplemented features.
88 To run a CPP replay you can use a template located in
89 [samples/capture_replay](../samples/capture_replay). First run your capture and ensure all capture
97 See [samples/BUILD.gn](../samples/BUILD.gn) for details. Then build and run your replay sample:
155 we've run go as high as ID 6.
163 Until we have samples building for Android, the replay sample must be run on desktop.
164 We will also be plumbing replay files into perf and correctness tests which will run on Android.
201 A job unit is a test batch. Each test has to go through 3 stages: capture run, replay build, and
202 replay run. The test batch batches the replay build stage of multiple tests together, and the
[all …]
|
| /external/autotest/server/site_tests/network_WiFi_SuspendTwice/ |
| D | control | 11 # Currently, it kills to many device on broken suspends.
17 this test to make sure we never regress. Try to run this late
18 in the cycle so if this test fails, we don't take other tests with
24 def run(machine):
30 parallel_simple(run, machines)
|
| /external/pigweed/pw_target_runner/ |
| D | docs.rst | 6 The target runner module implements a gRPC server designed to run executables
7 in parallel. These executables may be run directly on the host, or flashed to
13 executables among a pool of workers that run in parallel. This allows things
14 like unit tests to be run across multiple devices simultaneously, greatly
15 reducing the overall time it takes to run a collection of tests.
17 Additionally, the server allows many executables to be queued up at once and
18 scheduled across available devices, making it possible to automatically run unit
19 tests from a Ninja build after code is updated. This integrates nicely with the
20 ``pw watch`` command to re-run all affected unit tests after modifying code.
25 some custom workers for the desired target to run passed executables.
[all …]
|
| /external/autotest/server/site_tests/power_Monitoring/ |
| D | control | 9 PURPOSE = "Continuously measure power with servod while running client tests."
18 This wrapper test runs the tests specified under a given suite in a continuous
22 So this test is designed to collect all relevant power tests for many loops.
24 - There is a wider spread of battery charge percentages that tests run under
25 as tests don't recharge at the end individually.
48 suite: the test suite to run.
64 def run(machine):
68 parallel_simple(run, machines)
|
| /external/ltp/ |
| D | README.md | 6 project goal is to deliver tests to the open source community that validate the
31 **Be careful with these tests!**
33 Don't run them on production systems. Growfiles, doio, and iogen in particular
37 Quick guide to running the tests
56 the whole LTP, if you want to run a syscall testcase following should work.
83 $ ./foo_1-1.run-test
99 Some tests will be disabled if the configure script can not find their build
104 * If a tests fails due to a missing user or group, see the Quick Start section
107 To run all the test suites
114 Note that many test cases have to be executed as root.
[all …]
|
| /external/linux-kselftest/tools/testing/selftests/arm64/signal/ |
| D | README | 9 signal-test (setup/trigger/run/result/cleanup)
15 executable is used for each test since many tests complete successfully
17 to run each test unit in its own standalone process, so as to start each
20 - New tests can be simply defined in testcases/ dir providing a proper struct
22 custom run method is mandatory though)
27 - 'mangle_' tests: a real signal (SIGUSR1) is raised and used as a trigger
31 - 'fake_sigreturn_' tests: a brand new custom artificial sigframe structure
33 real signal return. This kind of tests does not use a trigger usually and
36 - Most of these tests are successfully passing if the process gets killed by
38 kind of tests it is extremely easy in fact to end-up injecting other
[all …]
|
| /external/llvm-project/llvm/docs/ |
| D | TestSuiteMakefileGuide.rst | 11 First, all tests are executed within the LLVM object directory tree.
15 To run the test suite, you need to use the following steps:
33 object directory tree) in which you want to run the test suite, just
51 #. You can now run the test suite from your build tree as follows:
65 In order to run the External tests in the ``test-suite`` module, you
69 missing or neglected, the External tests won't work.
75 This tells LLVM where to find any external tests. They are expected to
95 In addition to the regular "whole program" tests, the ``test-suite``
103 create the nightly test reports. To run the nightly tests, run
115 There are a number of ways to run the tests and generate output. The
[all …]
|
| /external/python/cpython2/Misc/ |
| D | README.valgrind | 20 many allocations (and frees), except for those that are forwarded
22 makes Python run much slower, especially when running under Valgrind.
23 You may need to run the tests in batches under Valgrind to keep
24 the memory usage down to allow the tests to complete. It seems to take
25 about 5 times longer to run --without-pymalloc.
31 This causes many spurious warnings, so it's easier to just skip it.
47 many errors like:
59 time, regardless of how many memory areas are under pymalloc's
|
| /external/ltp/testcases/open_posix_testsuite/stress/timers/ |
| D | plan.txt | 33 - Repeat key functional tests multiple times.
37 - Send many (1000s) of signals at the same time.
41 - Set memory to 95% and run through key clocks functions.
42 - Set memory to 95% and run through key timers functions.
46 - Set CPU to 95% and run through key clocks functions.
47 - Set CPU to 95% and run through key timers functions.
51 - Set up >10,000 timers and run through key clocks functions.
52 - Set up >10,000 timers and run through key timers functions.
54 * Will also perform kernel profiling on select stress tests.
|
| /external/ltp/testcases/open_posix_testsuite/scripts/ |
| D | locate-test | 13 Lists the tests (source/binary) available from the DIRECTORY directory
16 --buildonly List only tests that require building
17 --runnable List only tests that are executable
18 If you just want to build a test, but not run it,
35 not support TESTs compiled from many different sources.
|
| /external/skia/site/docs/dev/chrome/ |
| D | blink.md | 3 title: "Blink layout tests"
4 linkTitle: "Blink layout tests"
13 Changes affecting fewer than ~20 layout tests can be rebaselined without
16 1. Prepare your Skia change, taking note of which layout tests will turn red
17 \(see http://www.chromium.org/developers/testing/webkit-layout-tests for more
18 detail on running the Blink layout tests\).
21 …mium/src/+/master/third_party/blink/web_tests/TestExpectations), flagging tests expected to fail a…
26 …skipped test expectations you add earlier, an run `git cl rebaseline` which will prompt the automa…
32 Where a 'large number' or 'many' means more than about 20.
44 1. Make a change in Skia which will change many Blink layout tests.
[all …]
|
| /external/autotest/docs/ |
| D | faft-design-doc.md | 12 - [VBoot_Reference Library Tests](#vboot-reference-library-tests)
13 - [U-Boot vbexport/vboot Tests](#u-boot-vbexport-vboot-tests)
41 …ant; however, our current firmware is lack of automated tests. It only relies on the manual tests …
47 - Easy to integrate to our existing test infrastructure, i.e. deploy to test lab, run remotely, con…
61 …many) APIs which the main control logic is used. VBoot export APIs are the most, e.g., TPM, displa…
67 …tests are mostly focused on VBoot Bootstub and VBoot Main Firmware since they are complicated and …
73 <a name="vboot-reference-library-tests" />
78 Source: src/platform/vboot_reference/tests
80 …boot_reference provides a lot of tests varying from crypto algorithms to vboot main logic and cont…
82 
[all …]
|
| /external/skqp/site/dev/chrome/ |
| D | blink.md | 1 Blink layout tests
8 Changes affecting fewer than ~20 layout tests can be rebaselined without
11 1. Prepare your Skia change, taking note of which layout tests will turn red
12 \(see http://www.chromium.org/developers/testing/webkit-layout-tests for more
13 detail on running the Blink layout tests\).
16 …m/src/+/master/third_party/WebKit/LayoutTests/TestExpectations), flagging tests expected to fail a…
21 …skipped test expectations you add earlier, an run `git cl rebaseline` which will prompt the automa…
27 Where a 'large number' or 'many' means more than about 20.
39 1. Make a change in Skia which will change many Blink layout tests.
48 2. Make a change in Skia which will change many Blink layout tests.
[all …]
|
| /external/grpc-grpc/ |
| D | CONTRIBUTING.md | 19 ## Building & Running tests
22 of needing to build with many different build systems, a portable python
35 - To also run all the unit tests after building
40 You can also run `python tools/run_tests/run_tests.py --help` to discover useful command line flags…
41 …_tests) where you will also find guidance on how to run various other test suites (e.g. interop te…
45 To ease maintenance of language- and platform- specific build systems, many
50 As a rule of thumb, if you see the "sanity tests" failing you've most likely
103 - **All tests need to be passing** before your change can be merged.
104 We recommend you **run tests locally** before creating your PR to catch
|
| /external/protobuf/js/ |
| D | README.md | 42 Once you have `protoc` compiled, you can run the tests by typing:
52 This will run two separate copies of the tests: one that uses
55 If all of these tests pass, you know you have a working setup.
69 If you want to use Closure imports, your build should run a command
77 tests the generated files contain many `goog.provide` statements like:
85 The generated code will also `goog.require()` many types in the core library,
86 and they will require many types in the Google Closure library. So make sure
107 If you want to use CommonJS imports, your build should run a command
166 For more examples, see the tests. You can also look at the generated code
|
12345678910>>...22