se-edu / addressbook-level4 / 5133 / 1
94%
master: 94%

LAST BUILD BRANCH: 453-result-message
DEFAULT BRANCH: master
Ran
Files 81
Run time 4s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 93.908% (+0.2%) from 93.696%
5133.1

Pull #974

travis-ci

web-flow 
Adopt a uniform toString() format for value classes

The criteria used for determining which classes to implement the
standardized toString() methods are:

  * Must already implement equals()

    This is a strong signal that the classes are "value classes", that
    is, an instance is indistinguishable from another instance as long
    as their states are the same.

    Furthermore, these classes would likely be used with
    assertEquals(...) / assertNotEquals(...) in tests. When these
    assertions fail, the toString() representation of the
    expected/actual objects would be printed, and thus developers would
    benefit from the uniform toString() format which allows them to
    compare the state of the objects.

    On the other hand, classes which do not implement equals() would
    likely not be used with assertEquals(...) / assertNotEquals(...),
    and thus would not benefit from the uniform toString() format.

  * Does not already have its own suitable toString() representation

    For example, the toString() representations of Name, Phone, Email,
    Address, Tag are suitable enough for them, as they already convey
    the object's state, and thus would not benefit from the uniform
    toString() format. These classes are also only designed to contain
    one piece of information (e.g. for the Name class, a name, and for
    the Email class, an email), and thus would not benefit from the
    standardized toString() format which is designed for multiple pieces
    of information.
Pull Request #974: Adopt a uniform toString() format

1449 of 1543 relevant lines covered (93.91%)

0.94 hits per line

Source Files on job 5133.1