Re: Testing <type_traits>

[Martin Sebor <msebor at gmail dot com>]

On 10/07/2016 05:47 AM, Jonathan Wakely wrote:
> Most type traits have a requirements/typedefs.cc test like this:
>
> #include <type_traits>
>
> void test01()
> {
>  // Check for required typedefs
>  typedef std::has_virtual_destructor<int>    test_type;
>  typedef test_type::value_type            value_type;
>  typedef test_type::type            type;
>  typedef test_type::type::value_type        type_value_type;
>  typedef test_type::type::type            type_type;
> }
>
> Wouldn't it be better to do something like this instead?
>
>  typedef std::has_virtual_destructor<int>       test_type;
>  static_assert( std::is_same<test_type::value_type, bool>::value, "" );
>  typedef integral_constant<bool, test_type()()> bool_type;
>  static_assert( std::is_same<test_type::type, bool_type>::value, "");
>
> We should be checking that ::type is bool_constant, and if we do that
> then we don't need to bother testing type::type and type::value_type.

I agree that the existing test you showed seems quite weak
and ineffective and that the suggested test would be better.

My only (general) suggestion in developing tests for library
features it to try to avoid relying on other library features
and instead code them either in terms of lower-level (core)
constructs or in terms of independently developed testsuite
helpers.

For example, if std::foo is wrong or breaks, it's helpful if
it's revealed by a test for std::foo failing without also
causing tests for std::bar and std::baz to fail.  I realize
that this may be overly general or ambitious for some library
components and may not even be a good approach std::foo is
specified in terms of std::bar and std::baz, but in general
it's my experience that striving for this goal makes debugging
regressions introduced during development much easier.

Translating this to the first static_assert above might lead
to something like this:

  const bool *p = (test_type::value_type*)0;

Martin