An example could be that you have an external authentication provider that you need to call.

You send it a token and it returns an authenticated user.

This provider might be charging you per request, and calling it might take some extra time than if you had a fixed mock user for tests.

You probably want to test the external provider once, but not necessarily call it for every test that runs.

    # o isSuppressBatchUpdate: (NotRequired - Default false)
    #  Does it suppress batch update at loading data?
    #  When you have a data error, you may get details for the error
    #  by this property changing. Because it is possible that
    #  the BatchUpdateException information is very short for debug.
    #
    #; isSuppressBatchUpdate = false
    # - - - - - - - - - -/

        byte[] viaPassword = NtlmUtil.nTOWFv2(domain, user, password);

        // Assert: overloads consistent
        assertArrayEquals(viaHash, viaPassword, "Both overloads must compute same NTLMv2 key");

        // Changing domain should change the key (domain is part of MAC input)
        byte[] differentDomain = NtlmUtil.nTOWFv2("DOMAIN", user, password);

package cmd

import (
	"runtime"
	"testing"
	"time"
)

// WARNING:
//
// Expected source line number is hard coded, 35, in the
// following test. Adding new code before this test or changing its
// position will cause the line number to change and the test to FAIL
// Tests getSource().
func TestGetSource(t *testing.T) {
	currentSource := func() string { return getSource(2) }
	gotSource := currentSource()

 *
 * <p>To use this class the concrete subclass must implement the {@link
 * IteratorTester#newTargetIterator()} method. This is because it's impossible to test an Iterator
 * without changing its state, so the tester needs a steady supply of fresh Iterators.
 *
 * <p>If your iterator supports modification through {@code remove()}, you may wish to override the

      aa.lazySet(i, VALUES[i]);
      assertBitEquals(VALUES[i], aa.get(i));
      aa.lazySet(i, -3.0);
      assertBitEquals(-3.0, aa.get(i));
    }
  }

  /** compareAndSet succeeds in changing value if equal to expected else fails */
  public void testCompareAndSet() {
    AtomicDoubleArray aa = new AtomicDoubleArray(SIZE);
    for (int i : new int[] {0, SIZE - 1}) {
      double prev = 0.0;

		if ok {
			for i, queue := range config.QueueList {
				// Remove ARN not found queues, because we previously allowed
				// adding unexpected entries into the config.
				//
				// With newer config disallowing changing / turning off
				// notification targets without removing ARN in notification
				// configuration we won't see this problem anymore.
				if reflect.DeepEqual(queue.ARN, arnErr.ARN) && i < len(config.QueueList) {

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.
  - Improvements to Maven configuration.

Guidelines for any code contributions:

  1. Any significant changes should be accompanied by tests. The project already

 * services including WINS, broadcasts, DNS, and LMHOSTS. See
 * <a href="../../resolver.html">Setting Name Resolution Properties</a>
 * and the <code>jcifs.resolveOrder</code> property. Changing
 * jCIFS name resolution properties can greatly affect the behavior of
 * the client and may be necessary for proper operation.
 * <p>
 * This class should be used in favor of {@code InetAddress} to resolve

 *
 * <p>To use this class the concrete subclass must implement the {@link
 * IteratorTester#newTargetIterator()} method. This is because it's impossible to test an Iterator
 * without changing its state, so the tester needs a steady supply of fresh Iterators.
 *
 * <p>If your iterator supports modification through {@code remove()}, you may wish to override the