tree: 255dccbe3dd44594c0f1173ee40f7b4a171f164c [path history] [tgz]
  1. bad-syscall/
  2. bti/
  3. c11-condvar/
  4. c11-mutex/
  5. c11-thread/
  6. channel/
  7. channel-write-etc/
  8. clock/
  9. debuglog/
  10. default-exception-handler/
  11. elf-tls/
  12. event-pair/
  13. fifo/
  14. fpu/
  15. futex/
  16. handle-close/
  17. handle-dup/
  18. handle-info/
  19. handle-transfer/
  20. handle-wait/
  21. interrupt/
  22. job/
  23. memory-mapping/
  24. object-child/
  25. object-info/
  26. object-wait/
  27. pager/
  28. port/
  29. process/
  30. profile/
  31. pthread/
  32. pthread-barrier/
  33. pthread-tls/
  34. resource/
  35. socket/
  36. stack/
  37. stream/
  38. sync-completion/
  39. sync-condition/
  40. sync-mutex/
  41. system-event/
  42. threads/
  43. time/
  44. version/
  45. vmar/
  46. vmo/
  47. BUILD.gn
  48. libc-and-io-stubs.c
  49. OWNERS
  50. README.md
  51. test-main-with-filter.c
zircon/system/utest/core/README.md

utest/core

The “core” tests exist for one main purpose: To test basic functionality when things like devmgr aren't working.

If the kernel is told to run core-tests instead of devmgr, these tests will run without any userspace device manager, device drivers, io plumbing, etc.

Example usage

fx set core.x64   # any of {bringup,core}.{x64,arm64} are fine too.
fx build
fx core-tests [gtest-filter]

The helper fx command runs AEMU providing the specially-built core-tests.zbi as a -z argument.

gtest-filter can be optionally specified to run only the given gtest suite, e.g. fx core-tests 'FutexTest.*'.

Notes

The tests here are for “core” functionality (channels, etc.), but not all “core” functionality can go here. For example, you can‘t start a process in your test with launchpad because core tests are for when that functionality isn’t working. Core tests can't use fdio and launchpad uses fdio.

Since these tests can't use fdio core/libc-and-io-stubs.c stubs out the needed functions from fdio.