Clarifies how to implement MatcherInterface.

This commit is contained in:
zhanyong.wan 2013-03-01 01:47:35 +00:00
parent 320814aca0
commit 83f6b08b5f

View File

@ -112,10 +112,27 @@ class MatcherInterface {
virtual ~MatcherInterface() {}
// Returns true iff the matcher matches x; also explains the match
// result to 'listener', in the form of a non-restrictive relative
// clause ("which ...", "whose ...", etc) that describes x. For
// example, the MatchAndExplain() method of the Pointee(...) matcher
// should generate an explanation like "which points to ...".
// result to 'listener' if necessary (see the next paragraph), in
// the form of a non-restrictive relative clause ("which ...",
// "whose ...", etc) that describes x. For example, the
// MatchAndExplain() method of the Pointee(...) matcher should
// generate an explanation like "which points to ...".
//
// Implementations of MatchAndExplain() should add an explanation of
// the match result *if and only if* they can provide additional
// information that's not already present (or not obvious) in the
// print-out of x and the matcher's description. Whether the match
// succeeds is not a factor in deciding whether an explanation is
// needed, as sometimes the caller needs to print a failure message
// when the match succeeds (e.g. when the matcher is used inside
// Not()).
//
// For example, a "has at least 10 elements" matcher should explain
// what the actual element count is, regardless of the match result,
// as it is useful information to the reader; on the other hand, an
// "is empty" matcher probably only needs to explain what the actual
// size is when the match fails, as it's redundant to say that the
// size is 0 when the value is already known to be empty.
//
// You should override this method when defining a new matcher.
//