Ticket #12540 (closed Feature Requests: fixed)

Opened 6 months ago

Last modified 6 weeks ago

Provide customisation point for printing types in tests

Reported by: Tony Lewis <TonyELewis@…> Owned by: renficiaud
Milestone: Boost 1.64.0 Component: test
Version: Boost 1.61.0 Severity: Optimization
Keywords: test,customization,customisation,output,print,stream,insertion operator,print_log_value,BOOST_TEST_DONT_PRINT_LOG_VALUE Cc:


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.


Change History

comment:1 Changed 3 months ago by renficiaud

  • Owner changed from rogeeff to renficiaud
  • Status changed from new to assigned

comment:2 Changed 3 months ago by renficiaud

  • Milestone changed from To Be Determined to Boost 1.64.0

comment:3 Changed 3 months ago by renficiaud

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;

    printing_test::user_defined_type 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?

comment:4 Changed 3 months ago by 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.

comment:5 Changed 2 months ago by renficiaud

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

comment:6 Changed 8 weeks ago by Tony Lewis <TonyELewis@…>

Fantastic. Thanks very much for your work on this.

comment:7 Changed 6 weeks ago by renficiaud

Merged to master, rev af78890325948bed598361966fa7f5fc9560c41d

comment:8 Changed 6 weeks ago by renficiaud

  • Status changed from assigned to closed
  • Resolution set to fixed

comment:9 Changed 6 weeks ago by Tony Lewis <TonyELewis@…>

Great. Thanks very much.


Add a comment

Modify Ticket

Change Properties
<Author field>
as closed
The resolution will be deleted. Next status will be 'reopened'

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.