* #iterator()} method after the first, and whose iterator is always unmodifiable.
 *
 * <p>The {@code Iterable} specification does not make it absolutely clear what should happen on a
 * second invocation, so implementors have made various choices, including:
 *
 * <ul>
 *   <li>returning the same iterator again
 *   <li>throwing an exception of some kind

 *       other tests. We want to exclude the other tests (which Android can't handle) while
 *       continuing to run {@code FooTest} itself. This is exactly what happens with {@code
 *       AndroidIncompatible}. But I'm not sure what would happen if we annotated the {@code
 *       suite()} method with {@code Suppress}. Would {@code FooTest} itself be suppressed, too?

  }

  /**
   * Returns the {@link Method} instance for {@link #testAddAll_unsupportedNonePresent()} so that
   * tests can suppress it with {@code FeatureSpecificTestSuiteBuilder.suppressing()} while we
   * figure out what to do with <a href="http://goo.gl/qJBruX">{@code ConcurrentHashMap} support for
   * {@code entrySet().add()}</a>.
   */
  @J2ktIncompatible
  @GwtIncompatible // reflection

    validations:
      required: true

  - type: textarea
    attributes:
      label: Current Behavior
      description: What does the feature currently do?
    validations:
      required: true

  - type: textarea
    attributes:
      label: Desired Behavior
      description: What do you want it to do instead?
    validations:
      required: true

  - type: markdown
    attributes:
      value: >

    validations:
      required: true

  - type: textarea
    attributes:
      label: Expected Behavior
      description: What did you expect to happen?
    validations:
      required: true

  - type: textarea
    attributes:
      label: Actual Behavior
      description: What actually happened?
    validations:
      required: true

  - type: dropdown
    attributes:
      label: Packages

   * {@inheritDoc}
   *
   * <p>The {@code AbstractListTester} implementation overrides {@link
   * AbstractCollectionTester#expectContents(Collection)} to verify that the order of the elements
   * in the list under test matches what is expected.
   */
  @Override
  protected void expectContents(Collection<E> expectedCollection) {
    List<E> expectedList = Helpers.copyToList(expectedCollection);

 *   for (ThingToRun thingToRun : thingsToRun) {
 *     thingToRun.run(); // say this may throw an exception, but you want to
 *                       // always run all thingsToRun
 *   }
 * }
 * </pre>
 *
 * <p>This is what the code would become:
 *
 * <pre>
 * void runManyThings({@literal List<ThingToRun>} thingsToRun) {
 *   {@literal List<Exception>} exceptions = Lists.newArrayList();
 *   for (ThingToRun thingToRun : thingsToRun) {

   * of the function in [7.0, 10.0] is equivalent to the sum of the integrals of [7.0, 8.0], [8.0,
   * 9.0], [9.0, 10.0] (and so on), no matter what the function is. This guarantees that we handle
   * correctly requests of varying weight (permits), /no matter/ what the actual function is - so we
   * can tweak the latter freely. (The only requirement, obviously, is that we can compute its
   * integrals).
   *

    String data = "Hi There";

    checkSha1("b617318655057264e28bc0b6fb378c8ef146be00", key, data);
  }

  public void testRfc2202_hmacSha1_case2() {
    byte[] key = "Jefe".getBytes(UTF_8);
    String data = "what do ya want for nothing?";

    checkSha1("effcdf6ae5eb2fa2d27416d5f184df9c259a7c79", key, data);
  }

  public void testRfc2202_hmacSha1_case3() {
    byte[] key = fillByteArray(20, 0xaa);

-------------

Unless the change is a trivial fix such as for a typo, it's generally best to
start by opening a new issue describing the bug or feature you're intending to
fix. Even if you think it's relatively minor, it's helpful to know what people
are working on. And as mentioned above, API changes should be discussed
thoroughly before moving to code.

Some examples of types of pull requests that are immediately helpful: