tree: 615fe9bd2398610cf704a3bb2cfc24321b41ffdc [path history] [tgz]
  1. array_util.h
  2. BUILD.gn
  3. cpp_types_tests.cc
  4. decoding_tests.cc
  5. encoding_tests.cc
  6. extra_messages.h
  7. extra_messages.test.fidl
  8. extra_messages_fuchsia.test.fidl
  9. fidl_align_tests.cc
  10. fidl_coded_types.cc
  11. fidl_coded_types.h
  12. fidl_structs.h
  13. formatting_tests.cc
  14. handle_closing_tests.cc
  15. llcpp.test.fidl
  16. llcpp_client_test.cc
  17. llcpp_gen_api_test.cc
  18. llcpp_server_test.cc
  19. llcpp_transaction_tests.cc
  20. llcpp_types_tests.cc
  21. message_tests.cc
  22. messages.test.fidl
  23. on_error_handle_tests.cc
  24. README.md
  25. run_with_handle_policy_tests.cc
  26. run_with_handle_policy_tests.cmx
  27. validate_string_tests.cc
  28. validating_tests.cc
src/lib/fidl/c/walker_tests/README.md

FIDL definitions used in unit testing

The FIDL workflow is tested at multiple levels. fidl_coded_types.cc contains hand-written coding tables for the message types, and their corresponding C structure definitions are found in fidl_structs.h. Most tests in encoding/decoding exercise these manual coding table definitions. Though not one-to-one generated, messages.test.fidl contains a general outline of the FIDL definitions under test, for reference.

On the other hand, certain FIDL constructs are used in the higher layers, but are not supported by the C bindings right now, e.g. tables. fidlc is able to generate the coding tables for FIDL tables, but cannot generate their binding APIs. In order to unit test the table code paths, we will generate and check in their LLCPP bindings extra_messages.h from extra_messages.test.fidl.