* already covered by the corresponding Collection testers.
 *
 * @author Jared Levy
 */
@GwtCompatible
@Ignore("test runners must not instantiate and run this directly, only via suites we build")
// @Ignore affects the Android test runner, which respects JUnit 4 annotations on JUnit 3 tests.
@SuppressWarnings("JUnit4ClassUsedInJUnit3")

        // When
        request.setFileId(testFileId);

        // Then - verify through internal state (would need getter or reflection in real scenario)
        // Since we can't directly verify the internal state, we create a new request to test
        Smb2CloseRequest newRequest = new Smb2CloseRequest(mockConfig, testFileId);
        assertNotNull(newRequest, "Should create request with new file ID");
    }

        assertNotNull(tree1);
        assertNotNull(tree2);

        // When - Release session to trigger cleanup
        session.release();

        // Then - Trees should be cleared (we can't directly verify as it's internal,
        // but the cleanup code with synchronized block ensures it happens atomically)
        // The important part is that no exception occurs and the operation is atomic
    }

    /**

import java.util.Iterator;
import org.junit.Ignore;

/**
 * Tests for {@code Multiset.entrySet}.
 *
 * @author Jared Levy
 */
@GwtCompatible
@Ignore("test runners must not instantiate and run this directly, only via suites we build")
// @Ignore affects the Android test runner, which respects JUnit 4 annotations on JUnit 3 tests.
@SuppressWarnings("JUnit4ClassUsedInJUnit3")

So, you import `Query`, which is a function. And when you call it, it returns an instance of a class also named `Query`.

These functions are there (instead of just using the classes directly) so that your editor doesn't mark errors about their types.

That way you can use your normal editor and coding tools without having to add custom configurations to disregard those errors.

/// tip

Alternatively, you can perform the same steps that scripts does manually.

Go into the language directory, for the main docs in English it's at `docs/en/`:

```console
$ cd docs/en/
```

Then run `mkdocs` in that directory:

```console
$ mkdocs serve --dev-addr 127.0.0.1:8008
```

///

#### Typer CLI (optional)

        // Assert
        assertNotNull(handle);
        verify(mockDcerpcHandle, times(1)).sendrecv(any(MsrpcLsarOpenPolicy2.class));
        // We cannot directly assert the 'opened' field as it's private, but successful construction implies it.
    }

    @Test
    void constructor_shouldHandleNullServerSuccessfully() throws IOException {
        // Arrange

  @RegisterExtension
  @JvmField
  var platform = PlatformRule()

  private val handshakeCertificates = platform.localhostHandshakeCertificates()

  /** Ciphers in order we observed directly on the socket. */
  private lateinit var handshakeEnabledCipherSuites: List<String>

  /** Ciphers in order we observed on sslSocketFactory defaults. */
  private lateinit var defaultEnabledCipherSuites: List<String>

    (`tensorflow/tensorflow:devel` and `tensorflow/tensorflow:devel-gpu` are no
    longer supported for development). Use TF SIG Build Dockerfiles in
    development to avoid installing the packages directly on your system (in
    which case remember to change the directory from `/root` to `/tensorflow`
    once you get into the running container so `bazel` can find the `tensorflow`
    workspace).

a plugin, so following best practices is relatively straightforward.  For core plugins in gradle/gradle, it's easy for an object to be created without applying its associated plugin. For instance, Spring has a plugin that uses the Checkstyle task directly without applying the Checkstyle plugin.

Until we can provide the same guarantees for core plugins, we need to be more conservative for existing classes and not follow best practices. This means conventions need to be set in both a plugin...