Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: google/truth
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: master
Choose a base ref
...
head repository: google/truth
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: fix-param-names
Choose a head ref
Checking mergeability… Don’t worry, you can still create the pull request.
  • 2 commits
  • 22 files changed
  • 2 contributors

Commits on Jun 16, 2025

  1. Use more consistent parameter names. 

    (Note that this CL is yet another to [move us toward the terminology "actual" for the actual value](#203), albeit not in Javadoc but in parameter names.)

(previously in parameter-name standardization: cl/764397558, cl/770822182)

Assorted overanalysis:

- In `StringSubject`, I like using the somewhat vague parameter name "string" as a way to distinguish the methods that perform string matching from those that perform regex matching.
- I changed some "messageToPrepend" parameters to just "message." (See, for example, `assertWithMessage`.) It's true that the message is prepended, but that's true not only of the `(String messageToPrepend)` overloads but also the `(String format, Object... args)` overloads, so I don't want the parameter name to suggest that one is different than the other in that way.
- I have some reservations over using the name "element" for methods like `doesNotContain`, since the assertion is of course that the given value is _not_ an element. However, we also have methods like `doesNotContainEntry`, and I think it's difficult to pick a name for their parameters that doesn't include "key" and "value." So I think it's worth using the standard key/value/element terms throughout.
- I lack strong opinions on the parameter name for `containsNoneIn`. Given the logic above, I could see using "elements." But "excluded" seems OK, too?
- I have kind of a soft spot for the parameter name "unexpected" for `isNotEqualTo`. But I think that "other" has a couple things going for it: It's more like how I'd naturally describe the assertion ("make sure it's not equal to this other value"), and it matches some other assertion methods' parameters, including other not-equal-like assertions like `isLessThan`.
- I do sometimes like the existing parameter names _inside the implementation_, like in `check("size()").that(actual.size()).isEqualTo(expectedSize)`. But as usual, I think it's more important to optimize for callers.
- I considered trying to find another name for the parameter of `isIn(Iterable iterable)`. One option is "candidates," but somehow I don't like that as much for the complement, `isNotIn` (even though I think it still makes conceptual sense). But then I decided that I kind of liked plain "iterable": It means that `ComparableSubject` offers `isIn(Iterable iterable)` and `isIn(Range range)`, and that seems at least consistent.

PiperOrigin-RevId: 771789429
    @cpovirk
    cpovirk authored and Google Java Core Libraries committed Jun 16, 2025
    Configuration menu
    Copy the full SHA
    d15f673 View commit details
    Browse the repository at this point in the history

  2. Fix inconsistent parameter naming in core Truth subjects. 

    This change standardizes parameter names across various Subject classes in the `core/src/main/java/com/google/common/truth` directory.

Key changes include:
- Renaming `other` to `expected` in methods like `isNotEqualTo`, `isNotSameInstanceAs`, and in comparison methods within `ComparableSubject`, `DoubleSubject`, `FloatSubject`, and `LongSubject`.
- Standardizing sequence/string/prefix/suffix parameters in `StringSubject`.
- Ensuring `expected` or `element` is used consistently in `IterableSubject` and its `UsingCorrespondence` class.
- Aligning `value` to `expectedValue` in `MapSubject.UsingCorrespondence.doesNotContainEntry` and `MultimapSubject.UsingCorrespondence.doesNotContainEntry`.
    @google-labs-jules
    google-labs-jules[bot] committed Jun 16, 2025
    Configuration menu
    Copy the full SHA
    e0ea039 View commit details
    Browse the repository at this point in the history
Loading