* The {@linkplain State#TERMINATED TERMINATED} state is a terminal state in the transition
     * diagram. Therefore, if this method is called, no other methods will be called on the {@link
     * Listener}.
     *
     * @param from The previous state that is being transitioned from. Failure can occur in any

   * other methods are supported by the multimap and its views. When adding a key that doesn't
   * satisfy the predicate, the multimap's {@code put()}, {@code putAll()}, and {@code
   * replaceValues()} methods throw an {@link IllegalArgumentException}.
   *
   * <p>When methods such as {@code removeAll()} and {@code clear()} are called on the filtered

   * other methods are supported by the multimap and its views. When adding a key that doesn't
   * satisfy the predicate, the multimap's {@code put()}, {@code putAll()}, and {@code
   * replaceValues()} methods throw an {@link IllegalArgumentException}.
   *
   * <p>When methods such as {@code removeAll()} and {@code clear()} are called on the filtered

        // Then
        assertEquals(expectedLength, actualLength);
        verify(messageBlock).encode(dst, dstIndex);
    }

    @Test
    @DisplayName("Test setDigest and getDigest methods")
    void testSetAndGetDigest() {
        // Given
        doNothing().when(messageBlock).setDigest(digest);
        when(messageBlock.getDigest()).thenReturn(digest);

        // When

 * to implement the related methods as well. Finally, two collection views are provided: {@link
 * #elementSet} contains the distinct elements of the multiset "with duplicates collapsed", and
 * {@link #entrySet} is similar but contains {@link Entry Multiset.Entry} instances, each providing
 * both a distinct element and the count of that element.
 *
 * <p>In addition to these required methods, implementations of {@code Multiset} are expected to

    for (Method method : getInstanceMethodsToTest(instance.getClass(), minimalVisibility)) {
      testMethod(instance, method);
    }
  }

  ImmutableList<Method> getInstanceMethodsToTest(Class<?> c, Visibility minimalVisibility) {
    ImmutableList.Builder<Method> builder = ImmutableList.builder();
    for (Method method : minimalVisibility.getInstanceMethods(c)) {

        && method.getParameterTypes().length == 0 // only the seedless hash functions
        && !legacyHashingMethodNames.contains(method.getName());
  }

  static void assertSeededHashFunctionEquals(Class<?> clazz) throws Exception {
    Random random = new Random(RANDOM_SEED);
    for (Method method : clazz.getDeclaredMethods()) {

 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},
 *       typically because the type forbids nullable type arguments: For example, {@code

 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},
 *       typically because the type forbids nullable type arguments: For example, {@code

 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},
 *       typically because the type forbids nullable type arguments: For example, {@code