Provide customisation point for printing types in tests

[Tony Lewis <TonyELewis@…>]

AFAIU (from doc "Logging user defined types"), the current design gives users two options for handling output for their types in tests:

• Provide operator<<
• Prevent printing with BOOST_TEST_DONT_PRINT_LOG_VALUE()

...and all types must be printed.

I suggest that this is to rigid. For some types, users may not want to provide a global operator<<, or they may have already provided an operator<< or they may not own the type.

For these reasons, I think it would be better if Boost Test provided an explicit customization point that defaulted to calling operator<< but that could be overridden by the user to explictly control the Test printing without affecting operator<<.

In fact, I think boost::test_tools::tt_detail::print_log_value is already close to serving this purpose and perhaps it needs little more than being made part of the public interface and documented.

Thanks for all your work.

PS "D4381: Suggested Design for Customization Points" may be relevant here.

[Raffi Enficiaud]

Hi there,

I am not very familiar with the intrinsics of ADL and qualified/unqualified calls. What seems to be working right now in the branch topic/12540-printing-types-customisation-point is something like this:

namespace printing_test {
struct user_defined_type {
    int value;

    user_defined_type(int value_) : value(value_)
    {}

    bool operator==(int right) const {
        return right == value;
    }
};

std::ostream& boost_test_print_type(std::ostream& ostr, user_defined_type const& right) {
    ostr << "** value of my type is " << right.value << " **";
    return ostr;
}
}

BOOST_AUTO_TEST_CASE(test1)
{
    printing_test::user_defined_type t(10);
    BOOST_CHECK_EQUAL(t, 10);
    BOOST_TEST(t == 11);
}

However, if I move the definition of boost_test_print_type to another namespace, it does not find the definition anymore. This seems to be normal, but I do not know if this is what we want from the users' perspective.

What do you think?

[Tony Lewis <TonyELewis@…>]

Thanks very much for your work on this.

The changes on topic/12540-printing-types-customisation-point look like the sort of thing I was thinking of.

Yes, I think the idea of D4381 is that users customise by putting their function in the namespace of the type so that it gets picked up by ADL. What are your hesitations about this? It may be sub-optimal when users want to specify a boost_test_print_type() for a types in namespaces that they don't own and hence want to avoid polluting (eg std:: - I think I read that polluting std:: technically induces undefined behaviour). Still, I'd say it's still much better than expecting them to put an operator<< in there. Maybe it's possible to document that users can alternatively specialise the default boost_test_print_type template (and rename/move the namespace to something specific)? I don't know how that would play with the ideas of D4381.

I think I'd vote for: for now, document and release the current changes as a supported part of the interface. If the feedback is that users like the idea but want a way to avoid having to pollute namespaces that they don't own, consider extending the customisation interface. What do you think?

I think these changes are a really helpful improvement and are well worth highlighting to users.

Thanks again.

[Raffi Enficiaud]

Sorry I missed your reply, then it is good :) I will update the documentation. Should be fine for 1.64.

[Tony Lewis <TonyELewis@…>]

Fantastic. Thanks very much for your work on this.

[Raffi Enficiaud]

Merged to master, rev af78890325948bed598361966fa7f5fc9560c41d

[Tony Lewis <TonyELewis@…>]

Great. Thanks very much.