Серверное приложение на Java — бесплатный тест онлайн

Вопрос 1 из 30

Какой диагноз для кода по теме «Валидация» в разделе «Серверное приложение на Java» будет точным?

record TransferRequest(@jakarta.validation.constraints.NotNull Long from,
                       @jakarta.validation.constraints.Positive long amount) {}

Неограниченная очередь исполнителя хранит запросы дольше клиентского предела ожидания и расходует память на уже бесполезную работу. Передача HttpServletRequest в предметный сервис связывает бизнес-логику с веб-контейнером и усложняет тестирование. Проверка @NotNull не гарантирует, что accountId существует и доступен текущему пользователю. Запись полного заголовка Authorization превращает диагностический журнал в утечку токена. Прямой вызов метода контроллера не обнаружит неверный тип содержимого или ошибочную настройку преобразования JSON.

Вопрос 2 из 30

Что нужно отдельно проверить на границе контракта «Производительность и эксплуатация» в разделе «Серверное приложение на Java»?

// Минимальный пример
var executor = java.util.concurrent.Executors.newFixedThreadPool(32);
requestStream.forEach(r -> executor.submit(() -> handle(r)));

Тесты должны иметь конечные ограничения времени и завершать фоновые исполнители, иначе набор тестов может зависнуть уже после проверок. Значения с высокой кардинальностью вроде userId опасны как метки метрик, но допустимы в трассировках и журналах при подходящей политике хранения. Повторная проверка на сервере обязательна, даже если клиент уже валидировал поля. Циклическая зависимость между сервисами часто указывает на смешанные ответственности, а не на нехватку ленивого заместителя. Проверка готовности должна снимать экземпляр с трафика до завершения, а проверка жизнеспособности не должна зависеть от краткого сбоя внешней системы.

Вопрос 3 из 30

Что произойдёт с кодом по теме «Производительность и эксплуатация» в разделе «Серверное приложение на Java»?

var executor = java.util.concurrent.Executors.newFixedThreadPool(32);
requestStream.forEach(r -> executor.submit(() -> handle(r)));

Прямой вызов метода контроллера не обнаружит неверный тип содержимого или ошибочную настройку преобразования JSON. Локатор сервисов скрывает зависимости и переносит ошибку отсутствующего компонента в произвольный вызов во время выполнения. Проверка @NotNull не гарантирует, что accountId существует и доступен текущему пользователю. Передача HttpServletRequest в предметный сервис связывает бизнес-логику с веб-контейнером и усложняет тестирование. Неограниченная очередь исполнителя хранит запросы дольше клиентского предела ожидания и расходует память на уже бесполезную работу.

Вопрос 4 из 30

Что произойдёт с кодом по теме «Обработка HTTP» в разделе «Серверное приложение на Java»?

Order create(HttpServletRequest request) {
    return domainService.create(request);
}

Передача HttpServletRequest в предметный сервис связывает бизнес-логику с веб-контейнером и усложняет тестирование. Проверка @NotNull не гарантирует, что accountId существует и доступен текущему пользователю. Прямой вызов метода контроллера не обнаружит неверный тип содержимого или ошибочную настройку преобразования JSON. Локатор сервисов скрывает зависимости и переносит ошибку отсутствующего компонента в произвольный вызов во время выполнения. Запись полного заголовка Authorization превращает диагностический журнал в утечку токена.

Вопрос 5 из 30

Какое правило Java действует для темы «Наблюдаемость» в разделе «Серверное приложение на Java»?

Журналы, метрики и трассировки должны связываться идентификатором корреляции или трассировки и не раскрывать секреты. Конструкторная инъекция делает обязательные зависимости явными и позволяет создать полностью инициализированный объект. HTTP-слой переводит протокол в предметные команды и ответы, не смешивая коды транспорта с ядром модели. Синтаксическая валидация DTO и предметные инварианты решают разные задачи и должны давать разные ошибки. Серверный тест должен покрывать сериализацию, фильтры, авторизацию, транзакцию и контракт ошибки на подходящем уровне.

Вопрос 6 из 30

Как поведёт себя фрагмент по теме «Тестирование и диагностика» при разборе раздела «Серверное приложение на Java»?

var response = controller.create(new RequestDto(...));
assertEquals(201, response.status());

Передача HttpServletRequest в предметный сервис связывает бизнес-логику с веб-контейнером и усложняет тестирование. Запись полного заголовка Authorization превращает диагностический журнал в утечку токена. Локатор сервисов скрывает зависимости и переносит ошибку отсутствующего компонента в произвольный вызов во время выполнения. Неограниченная очередь исполнителя хранит запросы дольше клиентского предела ожидания и расходует память на уже бесполезную работу. Прямой вызов метода контроллера не обнаружит неверный тип содержимого или ошибочную настройку преобразования JSON.

Вопрос 7 из 30

Какое правило Java действует для темы «Тестирование и диагностика» в разделе «Серверное приложение на Java»?

Конструкторная инъекция делает обязательные зависимости явными и позволяет создать полностью инициализированный объект. Ограниченные очереди, конечное время ожидания, регулирование входной нагрузки и корректное завершение работы являются частью архитектуры сервера. Журналы, метрики и трассировки должны связываться идентификатором корреляции или трассировки и не раскрывать секреты. Серверный тест должен покрывать сериализацию, фильтры, авторизацию, транзакцию и контракт ошибки на подходящем уровне. Синтаксическая валидация DTO и предметные инварианты решают разные задачи и должны давать разные ошибки.

Вопрос 8 из 30

Как поведёт себя фрагмент по теме «Наблюдаемость» при разборе раздела «Серверное приложение на Java»?

log.info("request headers={} body={}", request.getHeaders(), request.body());

Запись полного заголовка Authorization превращает диагностический журнал в утечку токена. Проверка @NotNull не гарантирует, что accountId существует и доступен текущему пользователю. Передача HttpServletRequest в предметный сервис связывает бизнес-логику с веб-контейнером и усложняет тестирование. Запись текущего времени и абсолютного пути в JAR делает хеш артефакта разным при каждом запуске. Прямой вызов метода контроллера не обнаружит неверный тип содержимого или ошибочную настройку преобразования JSON.

Вопрос 9 из 30

Какой инженерный компромисс характерен для темы «Обработка HTTP» в разделе «Серверное приложение на Java»?

Тонкий контроллер облегчает повторное использование кода, но у координации вызовов и политики ошибок всё равно должен быть явный владелец. Контейнер внедрения зависимостей упрощает связывание компонентов, но не должен превращать каждый объект данных и каждую функцию в глобальный компонент. Ранняя валидация сокращает лишнюю работу, но правила, зависящие от состояния, нельзя надёжно вынести только в аннотации DTO. Полный сквозной тест повышает доверие, но сочетание узких контрактных и нескольких сквозных сценариев быстрее локализует дефект. Жёсткий лимит защищает процесс, но часть нагрузки получит явный отказ; повторять запрос можно только при безопасной семантике операции.

Вопрос 10 из 30

Какая правка точнее всего устраняет причину проблемы по теме «Тестирование и диагностика» в разделе «Серверное приложение на Java»?

// Фрагмент на ревью
var response = controller.create(new RequestDto(...));
assertEquals(201, response.status());

Извлечь и валидировать DTO, затем вызвать сервис с предметными типами. Добавить HTTP-тест через реальный конвейер веб-платформы и отдельные модульные тесты ядра. Ввести ограниченную очередь, передачу крайнего срока выполнения, отмену и метрики отказа. После проверки формы выполнить авторизацию и предметную проверку внутри транзакционной операции. Передавать порты через конструктор и собирать граф в точке сборки приложения.

Вопрос 11 из 30

Какое изменение сделает код по теме «Производительность и эксплуатация» в разделе «Серверное приложение на Java» надёжнее?

// Фрагмент на ревью
var executor = java.util.concurrent.Executors.newFixedThreadPool(32);
requestStream.forEach(r -> executor.submit(() -> handle(r)));

Добавить HTTP-тест через реальный конвейер веб-платформы и отдельные модульные тесты ядра. Ввести ограниченную очередь, передачу крайнего срока выполнения, отмену и метрики отказа. Записывать безопасные идентификаторы и структурированные поля, секреты маскировать или исключать. После проверки формы выполнить авторизацию и предметную проверку внутри транзакционной операции. Передавать порты через конструктор и собирать граф в точке сборки приложения.

Вопрос 12 из 30

Что нужно отдельно проверить на границе контракта «Наблюдаемость» в разделе «Серверное приложение на Java»?

// Минимальный пример
log.info("request headers={} body={}", request.getHeaders(), request.body());

Идемпотентность метода определяется эффектом и контрактом, а не только названием маршрута. Значения с высокой кардинальностью вроде userId опасны как метки метрик, но допустимы в трассировках и журналах при подходящей политике хранения. Циклическая зависимость между сервисами часто указывает на смешанные ответственности, а не на нехватку ленивого заместителя. Проверка готовности должна снимать экземпляр с трафика до завершения, а проверка жизнеспособности не должна зависеть от краткого сбоя внешней системы. Тесты должны иметь конечные ограничения времени и завершать фоновые исполнители, иначе набор тестов может зависнуть уже после проверок.

Вопрос 13 из 30

Как лучше исправить или прояснить поведение темы «Управление зависимостями» в разделе «Серверное приложение на Java»?

// Фрагмент на ревью
class BillingService {
    void charge(Order o) {
        var gateway = AppContext.get(PaymentGateway.class);
        gateway.charge(o.total());
    }
}

Записывать безопасные идентификаторы и структурированные поля, секреты маскировать или исключать. Добавить HTTP-тест через реальный конвейер веб-платформы и отдельные модульные тесты ядра. Извлечь и валидировать DTO, затем вызвать сервис с предметными типами. Ввести ограниченную очередь, передачу крайнего срока выполнения, отмену и метрики отказа. Передавать порты через конструктор и собирать граф в точке сборки приложения.

Вопрос 14 из 30

Какое утверждение о механизме «Управление зависимостями» верно в контексте раздела «Серверное приложение на Java»?

Серверный тест должен покрывать сериализацию, фильтры, авторизацию, транзакцию и контракт ошибки на подходящем уровне. Синтаксическая валидация DTO и предметные инварианты решают разные задачи и должны давать разные ошибки. Конструкторная инъекция делает обязательные зависимости явными и позволяет создать полностью инициализированный объект. Конструкторная инъекция делает обязательные зависимости явными и не позволяет создать полностью инициализированный объект. Журналы, метрики и трассировки должны связываться идентификатором корреляции или трассировки и не раскрывать секреты.

Вопрос 15 из 30

Что следует изменить в разделе «Серверное приложение на Java», чтобы сохранить замысел и соблюсти контракт «Валидация»?

// Фрагмент на ревью
record TransferRequest(@jakarta.validation.constraints.NotNull Long from,
                       @jakarta.validation.constraints.Positive long amount) {}

Добавить HTTP-тест через реальный конвейер веб-платформы и отдельные модульные тесты ядра. Ввести ограниченную очередь, передачу крайнего срока выполнения, отмену и метрики отказа. После проверки формы выполнить авторизацию и предметную проверку внутри транзакционной операции. Извлечь и валидировать DTO, затем вызвать сервис с предметными типами. Записывать безопасные идентификаторы и структурированные поля, секреты маскировать или исключать.

Вопрос 16 из 30

Какое правило Java действует для темы «Валидация» в разделе «Серверное приложение на Java»?

Серверный тест должен покрывать сериализацию, фильтры, авторизацию, транзакцию и контракт ошибки на подходящем уровне. HTTP-слой переводит протокол в предметные команды и ответы, не смешивая коды транспорта с ядром модели. Ограниченные очереди, конечное время ожидания, регулирование входной нагрузки и корректное завершение работы являются частью архитектуры сервера. Синтаксическая валидация DTO и предметные инварианты решают разные задачи и должны давать разные ошибки. Конструкторная инъекция делает обязательные зависимости явными и позволяет создать полностью инициализированный объект.

Вопрос 17 из 30

Какое замечание о сопровождении или производительности темы «Производительность и эксплуатация» в разделе «Серверное приложение на Java» справедливо?

Полный сквозной тест повышает доверие, но сочетание узких контрактных и нескольких сквозных сценариев быстрее локализует дефект. Подробность помогает расследованию, однако каждое поле имеет цену хранения, приватности и поисковой кардинальности. Тонкий контроллер облегчает повторное использование кода, но у координации вызовов и политики ошибок всё равно должен быть явный владелец. Жёсткий лимит защищает процесс, но часть нагрузки получит явный отказ; повторять запрос можно только при безопасной семантике операции. Ранняя валидация сокращает лишнюю работу, но правила, зависящие от состояния, нельзя надёжно вынести только в аннотации DTO.

Вопрос 18 из 30

Что важно учитывать при применении механизма «Наблюдаемость» из раздела «Серверное приложение на Java» в рабочем проекте?

Контейнер внедрения зависимостей упрощает связывание компонентов, но не должен превращать каждый объект данных и каждую функцию в глобальный компонент. Полный сквозной тест повышает доверие, но сочетание узких контрактных и нескольких сквозных сценариев быстрее локализует дефект. Жёсткий лимит защищает процесс, но часть нагрузки получит явный отказ; повторять запрос можно только при безопасной семантике операции. Подробность помогает расследованию, однако каждое поле имеет цену хранения, приватности и поисковой кардинальности. Ранняя валидация сокращает лишнюю работу, но правила, зависящие от состояния, нельзя надёжно вынести только в аннотации DTO.

Вопрос 19 из 30

Какое ограничение механизма «Валидация» нельзя упускать при работе с разделом «Серверное приложение на Java»?

// Минимальный пример
record TransferRequest(@jakarta.validation.constraints.NotNull Long from,
                       @jakarta.validation.constraints.Positive long amount) {}

Проверка готовности должна снимать экземпляр с трафика до завершения, а проверка жизнеспособности не должна зависеть от краткого сбоя внешней системы. Тесты должны иметь конечные ограничения времени и завершать фоновые исполнители, иначе набор тестов может зависнуть уже после проверок. Циклическая зависимость между сервисами часто указывает на смешанные ответственности, а не на нехватку ленивого заместителя. Идемпотентность метода определяется эффектом и контрактом, а не только названием маршрута. Повторная проверка на сервере обязательна, даже если клиент уже валидировал поля.

Вопрос 20 из 30

Какой инженерный компромисс характерен для темы «Управление зависимостями» в разделе «Серверное приложение на Java»?

Тонкий контроллер облегчает повторное использование кода, но у координации вызовов и политики ошибок всё равно должен быть явный владелец. Жёсткий лимит защищает процесс, но часть нагрузки получит явный отказ; повторять запрос можно только при безопасной семантике операции. Контейнер внедрения зависимостей упрощает связывание компонентов, но не должен превращать каждый объект данных и каждую функцию в глобальный компонент. Полный сквозной тест повышает доверие, но сочетание узких контрактных и нескольких сквозных сценариев быстрее локализует дефект. Подробность помогает расследованию, однако каждое поле имеет цену хранения, приватности и поисковой кардинальности.

Вопрос 21 из 30

Что нужно отдельно проверить на границе контракта «Обработка HTTP» в разделе «Серверное приложение на Java»?

// Минимальный пример
Order create(HttpServletRequest request) {
    return domainService.create(request);
}

Тесты должны иметь конечные ограничения времени и завершать фоновые исполнители, иначе набор тестов может зависнуть уже после проверок. Циклическая зависимость между сервисами часто указывает на смешанные ответственности, а не на нехватку ленивого заместителя. Идемпотентность метода определяется эффектом и контрактом, а не только названием маршрута. Повторная проверка на сервере обязательна, даже если клиент уже валидировал поля. Значения с высокой кардинальностью вроде userId опасны как метки метрик, но допустимы в трассировках и журналах при подходящей политике хранения.

Вопрос 22 из 30

Что следует изменить в разделе «Серверное приложение на Java», чтобы сохранить замысел и соблюсти контракт «Наблюдаемость»?

// Фрагмент на ревью
log.info("request headers={} body={}", request.getHeaders(), request.body());

Добавить HTTP-тест через реальный конвейер веб-платформы и отдельные модульные тесты ядра. Ввести ограниченную очередь, передачу крайнего срока выполнения, отмену и метрики отказа. Связать отметки сборщика мусора с релизом и снимком кучи, не делая вывод по одной строке. После проверки формы выполнить авторизацию и предметную проверку внутри транзакционной операции. Записывать безопасные идентификаторы и структурированные поля, секреты маскировать или исключать.

Вопрос 23 из 30

Что важно учитывать при применении механизма «Тестирование и диагностика» из раздела «Серверное приложение на Java» в рабочем проекте?

Быстрое смягчение последствий восстанавливает сервис, но отдельный анализ нужен, чтобы не принять временную меру за окончательный ремонт. Тонкий контроллер облегчает повторное использование кода, но у координации вызовов и политики ошибок всё равно должен быть явный владелец. Жёсткий лимит защищает процесс, но часть нагрузки получит явный отказ; повторять запрос можно только при безопасной семантике операции. Ранняя валидация сокращает лишнюю работу, но правила, зависящие от состояния, нельзя надёжно вынести только в аннотации DTO. Полный сквозной тест повышает доверие, но сочетание узких контрактных и нескольких сквозных сценариев быстрее локализует дефект.

Вопрос 24 из 30

Какое утверждение о механизме «Производительность и эксплуатация» верно в контексте раздела «Серверное приложение на Java»?

Ограниченные очереди, конечное время ожидания, регулирование входной нагрузки и корректное завершение работы являются частью архитектуры сервера. Конструкторная инъекция делает обязательные зависимости явными и позволяет создать полностью инициализированный объект. Пул ограничивает число дорогих физических соединений; время ожидания свободного соединения должно быть конечным и наблюдаемым. Серверный тест должен покрывать сериализацию, фильтры, авторизацию, транзакцию и контракт ошибки на подходящем уровне. Синтаксическая валидация DTO и предметные инварианты решают разные задачи и должны давать разные ошибки.

Вопрос 25 из 30

На какое правило следует опираться при разборе темы «Обработка HTTP» в разделе «Серверное приложение на Java»?

Синтаксическая валидация DTO и предметные инварианты решают разные задачи и должны давать разные ошибки. Серверный тест должен покрывать сериализацию, фильтры, авторизацию, транзакцию и контракт ошибки на подходящем уровне. После аварии нужен воспроизводящий тест на минимальном сценарии и проверка защитного механизма под отказом. Конструкторная инъекция делает обязательные зависимости явными и позволяет создать полностью инициализированный объект. HTTP-слой переводит протокол в предметные команды и ответы, не смешивая коды транспорта с ядром модели.

Вопрос 26 из 30

В каком дополнительном сценарии вывод о теме «Тестирование и диагностика» в разделе «Серверное приложение на Java» может оказаться неверным?

// Минимальный пример
var response = controller.create(new RequestDto(...));
assertEquals(201, response.status());

Идемпотентность метода определяется эффектом и контрактом, а не только названием маршрута. Сообщение Allocation Failure часто обозначает причину запуска обычной сборки, а не уже произошедшую ошибку нехватки памяти. Циклическая зависимость между сервисами часто указывает на смешанные ответственности, а не на нехватку ленивого заместителя. Значения с высокой кардинальностью вроде userId опасны как метки метрик, но допустимы в трассировках и журналах при подходящей политике хранения. Тесты должны иметь конечные ограничения времени и завершать фоновые исполнители, иначе набор тестов может зависнуть уже после проверок.

Вопрос 27 из 30

Какой инженерный компромисс характерен для темы «Валидация» в разделе «Серверное приложение на Java»?

Полный сквозной тест повышает доверие, но сочетание узких контрактных и нескольких сквозных сценариев быстрее локализует дефект. Ранняя валидация сокращает лишнюю работу, но правила, зависящие от состояния, нельзя надёжно вынести только в аннотации DTO. Жёсткая фиксация повышает повторяемость, но требует автоматического процесса безопасного обновления и проверки уязвимостей. Жёсткий лимит защищает процесс, но часть нагрузки получит явный отказ; повторять запрос можно только при безопасной семантике операции. Тонкий контроллер облегчает повторное использование кода, но у координации вызовов и политики ошибок всё равно должен быть явный владелец.

Вопрос 28 из 30

Какое ограничение механизма «Управление зависимостями» нельзя упускать при работе с разделом «Серверное приложение на Java»?

class BillingService {
    void charge(Order o) {
        var gateway = AppContext.get(PaymentGateway.class);
        gateway.charge(o.total());
    }
// ...

Проверка готовности должна снимать экземпляр с трафика до завершения, а проверка жизнеспособности не должна зависеть от краткого сбоя внешней системы. Один снимок не доказывает взаимную блокировку, если приложение просто находится в краткой фазе ожидания. Циклическая зависимость между сервисами часто указывает на смешанные ответственности, а не на нехватку ленивого заместителя. Повторная проверка на сервере обязательна, даже если клиент уже валидировал поля. Тесты должны иметь конечные ограничения времени и завершать фоновые исполнители, иначе набор тестов может зависнуть уже после проверок.

Вопрос 29 из 30

Какое изменение сделает код по теме «Обработка HTTP» в разделе «Серверное приложение на Java» надёжнее?

// Фрагмент на ревью
Order create(HttpServletRequest request) {
    return domainService.create(request);
}

Передавать порты через конструктор и собирать граф в точке сборки приложения. Извлечь и валидировать DTO, затем вызвать сервис с предметными типами. Добавить HTTP-тест через реальный конвейер веб-платформы и отдельные модульные тесты ядра. После проверки формы выполнить авторизацию и предметную проверку внутри транзакционной операции. Записывать безопасные идентификаторы и структурированные поля, секреты маскировать или исключать.

Вопрос 30 из 30

Что произойдёт с кодом по теме «Управление зависимостями» в разделе «Серверное приложение на Java»?

class BillingService {
    void charge(Order o) {
        var gateway = AppContext.get(PaymentGateway.class);
        gateway.charge(o.total());
    }
}

Неограниченная очередь исполнителя хранит запросы дольше клиентского предела ожидания и расходует память на уже бесполезную работу. Локатор сервисов скрывает зависимости и переносит ошибку отсутствующего компонента в произвольный вызов на этапе компиляции. Прямой вызов метода контроллера не обнаружит неверный тип содержимого или ошибочную настройку преобразования JSON. Локатор сервисов скрывает зависимости и переносит ошибку отсутствующего компонента в произвольный вызов во время выполнения. Передача HttpServletRequest в предметный сервис связывает бизнес-логику с веб-контейнером и усложняет тестирование.