Lines Matching full:tests
12 * **Unit tests**: written in C++ using the googletest unit testing library.
13 * **Shell tests**: Integration tests that test the debugger through the command
14 line. These tests interact with the debugger either through the command line
17 these as *lit tests* in LLVM, although lit is the test driver and ShellTest
21 * **API tests**: Integration tests that interact with the debugger through the
31 Unit Tests
34 Unit tests are located under ``lldb/unittests``. If it's possible to test
39 tests that have the necessary boiler plate, but this is something we could
42 Shell Tests
45 Shell tests are located under ``lldb/test/Shell``. These tests are generally
47 ``lldb-test`` using ``FileCheck``. Shell tests are generally small and fast to
56 Obviously shell tests are great for testing the command line driver itself or
63 A good rule of thumb is to prefer shell tests when what is being tested is
64 relatively simple. Expressivity is limited compared to the API tests, which
69 inferiors. For shell tests, they have to be relatively simple. The
72 tests are limited to single lines of shell commands with compiler and linker
75 On the same topic, another interesting aspect of the shell tests is that there
77 tests almost always require a fully functional executable. This enables testing
81 Finally, the shell tests always run in batch mode. You start with some input
89 API Tests
92 API tests are located under ``lldb/test/API``. They are run with the
93 ``dotest.py``. Tests are written in Python and test binaries (inferiors) are
94 compiled with Make. The majority of API tests are end-to-end tests that compile
107 Most of the tests are structured as a binary being debugged, so there will be
118 one or more test methods, that start with ``test_``. Many tests define
128 shared across tests, we extract it into a utility in ``lldbutil``. It's always
137 tests using decorators. You'll see them a lot. The debugger can be sensitive to
159 while individual make files can be used to build more advanced tests.
186 the runtime of the tests and has a large ongoing cost.
190 generic tests, so running the test suite with the feature enabled is a good way
192 genericness makes them poor regression tests. Because it's not clear what a
195 tests tend to look very similar, it's easy for a simple bug to cause hundreds of
196 tests to fail in the same way.
201 test for any bug found that way. Often, there will be many tests failing, but a
202 lot of then will have the same root cause. These tests will be easier to debug
207 program being debugged. The fact that the API tests work with different
208 variants mean that more general tests should be API tests, so that they can be
211 Guidelines for API tests
214 API tests are expected to be fast, reliable and maintainable. To achieve this
215 goal, API tests should conform to the following guidelines in addition to normal
235 tests the `SBProcess`, `SBThread`, and `SBFrame` classes. The same is true
236 for tests that exercise breakpoints, watchpoints and sanitizers.
249 use a cache that is shared between all API tests and that contains
267 **Identifiers in tests should be simple and descriptive.**
270 either be kept simple for small tests (e.g., ``A``, ``B``, ...) or have some
288 Avoid writing your tests on top of ``self.expect(...)`` calls that check
291 commands harder and the resulting tests are often prone to accepting
371 These features can be use to properly mark your test class or method for platform-specific tests, c…
412 Running The Tests
433 compiler that was used to build LLDB. To build the tests with a different
455 * Use ``check-lldb-unit`` to run just the unit tests.
456 * Use ``check-lldb-api`` to run just the SB API tests.
457 * Use ``check-lldb-shell`` to run just the shell tests.
460 target. For example, to run all the tests in ``ObjectFile``, you can use the
461 target ``check-lldb-shell-objectfile``. However, because the unit tests and API
462 tests don't actually live under ``lldb/test``, this convenience is only
463 available for the shell tests.
477 Because lit automatically scans a directory for tests, it's also possible to
478 pass a subdirectory to run a specific subset of the tests.
485 For the SB API tests it is possible to forward arguments to ``dotest.py`` by
496 Running a Specific Test or Set of Tests: API Tests
500 target above, it is possible to run individual LLDB tests. If you have a CMake
519 off), all tests in that directory will be executed:
537 Running a Specific Test or Set of Tests: Unit Tests
540 The unit tests are simple executables, located in the build directory under ``tools/lldb/unittests`…
542 To run them, just run the test binary, for example, to run all the Host tests:
576 Running tests in QEMU System Emulation Environment