import java.lang.annotation.Target;

/**
 * Signifies that a test should not be run under Android. This annotation is respected only by our
 * Google-internal Android suite generators. Note that those generators also suppress any test
 * annotated with LargeTest.
 *
 * <p>Why use a custom annotation instead of {@code android.test.suitebuilder.annotation.Suppress}?
 * I'm not completely sure that this is the right choice, but it has various advantages:
 *

 * iterator} method only once, and should be tested using this class. Exceptions to this rule should
 * be clearly documented.
 *
 * <p>Note that although your APIs should be liberal in what they accept, your methods which
 * <i>return</i> iterables should make every attempt to return ones of the robust variety.
 *
 * <p>This testing utility is not thread-safe.
 *
 * @author Kevin Bourrillion

   * <ul>
   *   <li>If {@code exceptions} has a single exception and that exception is a {@link
   *       RuntimeException}, return it
   *   <li>If {@code exceptions} has a single exceptions and that exceptions is not a
   *       {@link RuntimeException}, return a simple {@code RuntimeException} that wraps it
   *   <li>Otherwise, return an instance of {@link ClusterException} that wraps the first exception

public class AbstractListTester<E extends @Nullable Object> extends AbstractCollectionTester<E> {
  /*
   * Previously we had a field named list that was initialized to the value of
   * collection in setUp(), but that caused problems when a tester changed the
   * value of list or collection but not both.
   */
  protected final List<E> getList() {
    return (List<E>) collection;
  }

  /**

  }

  /**
   * 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

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:

  - Fixing a bug without changing a public API.
  - Fixing or improving documentation.

      assertTrue(burst <= 1000);
      long afterBurst = measureTotalTimeMillis(limiter, oneSecWorthOfWork, new Random());
      // but work beyond that must take at least one second
      assertTrue(afterBurst >= 1000);
    }
  }

  /**
   * This neat test shows that no matter what weights we use in our requests, if we push X amount of
   * permits in a cool state, where X = rate * timeToCoolDown, and we have specified a

   * cannot implement that interface in source code in a way that will compile on both Java 7 and
   * Java 8. If we include the {@code getAnnotatedBounds()} method then its return type means it
   * won't compile on Java 7, while if we don't include the method then the compiler will complain

    }
  }

  /*
   * Whenever an implementation uses `instanceof` on a parameter instance, the test has to know that
   * (so much for "black box") and try instances that both do and don't pass the check. The "don't"
   * half of that is more awkward to arrange...
   */
  private static <T> Iterable<T> iterable(final Collection<T> collection) {
    // return collection::iterator;

   *       {@code MapJoiner} method that accepts entries as input, and receive output of the form
   *       {@code key1=A&key1=B&key2=C}.
   *   <li>To output a single entry for each key, pass {@code multimap.asMap()} to a {@code
   *       MapJoiner} method that accepts a map as input, and receive output of the form {@code
   *       key1=[A, B]&key2=C}.
   * </ul>
   *