tree: 8b333883f1df4c54b86d31ac9b3e15866eb63cef [path history] [tgz]
  1. array_util.h
  2. BUILD.gn
  3. conformance_test_utils.h
  4. cpp_types_tests.cc
  5. decoding_tests.cc
  6. encoding_tests.cc
  7. extra_messages.h
  8. extra_messages.test.fidl
  9. extra_messages_fuchsia.test.fidl
  10. fidl_align_tests.cc
  11. fidl_coded_types.cc
  12. fidl_coded_types.h
  13. fidl_structs.h
  14. formatting_tests.cc
  15. handle_closing_tests.cc
  16. llcpp.test.fidl
  17. llcpp_client_test.cc
  18. llcpp_gen_api_test.cc
  19. llcpp_server_test.cc
  20. llcpp_transaction_tests.cc
  21. llcpp_types_tests.cc
  22. message_tests.cc
  23. messages.test.fidl
  24. on_error_handle_tests.cc
  25. README.md
  26. run_with_handle_policy_tests.cc
  27. run_with_handle_policy_tests.cmx
  28. validate_string_tests.cc
  29. 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.