This seems like a reasonable addition, but we need to consider carefully
what conditions are valid for skipping tests, otherwise it makes it too
easy for ODP APIs to become optional.  Can we include some guidelines
here?  Especially given that we have the ability to support
platform-specific tests in addition to global tests, we should clarify
under what conditions a global test would be made conditional vs. just
having a platform-specific test for a feature that may be unique to a
particular platform.

On Wed, Jan 13, 2016 at 11:08 AM, Christophe Milard <
christophe.mil...@linaro.org> wrote:

> Documentation on conditional test is added here, as it seemed to be missing
>
> Signed-off-by: Christophe Milard <christophe.mil...@linaro.org>
> ---
>  doc/implementers-guide/implementers-guide.adoc | 29
> ++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
>
> diff --git a/doc/implementers-guide/implementers-guide.adoc
> b/doc/implementers-guide/implementers-guide.adoc
> index eb076cf..57be4b2 100644
> --- a/doc/implementers-guide/implementers-guide.adoc
> +++ b/doc/implementers-guide/implementers-guide.adoc
> @@ -389,4 +389,33 @@ It's expected that early in the development cycle of
> a new implementation the
>  inactive list will be quite long, but it should shrink over time as more
> parts
>  of the API are implemented.
>
> +==== conditionnal tests ====
> +
> +Some tests may require specific conditions to make sense: for instance, on
> +pktio, checking that sending a packet larger than the MTU is rejected
> only makes
> +sense if packets can indeed, on that ODP implementation, exceed the MTU.
> +A test can be marked conditionnal as follows:
> +
> +[source,c]
> +------------------
> +odp_testinfo_t foo_tests[] = {
> +       ...
> +       ODP_TEST_INFO_CONDITIONAL(foo_test_x, foo_check_x),
> +       ...
> +       ODP_TEST_INFO_NULL
> +};
> +
> +odp_suiteinfo_t foo_suites[] = {
> +       {"Foo", foo_suite_init, foo_suite_term, foo_tests},
> +       ODP_SUITE_INFO_NULL
> +};
> +------------------
> +
> +Foo_test_x is the usual test function. Foo_check_x is the test
> precondition,
> +i.e. a function returning an bollean (int).
> +It is called before the test suite is started. If it returns true, the
> +test (foo_test_x) is run. If the precondition function (foo_check_x above)
> +returns false, the test is not relevant (or impossible to perform) and it
> will
> +be skipped.
> +
>  include::../glossary.adoc[]
> --
> 2.1.4
>
> _______________________________________________
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Reply via email to