Где тесты?

Если у тебя нормальные отношения с тестировщиками, то у них всегда уточнить можно...

Прогонять в голове кучи тест-кейсов на алгоритм, конечно, весело, но на практике не применимо. Как только алгоритм будет сложнее, чем простой, это станет невозможно делать в голове, если ты не гений какой-нибудь. Алгоритмы для того и нужно покрывать тестами, чтобы их было проще отлаживать. В реальной жизни никто не сидит и не подставляет в своей голове разные последовательности и не высчитывает ответ в голове.

Алгоритмы для того и нужно покрывать тестами, чтобы их было проще отлаживать. Так покрывай, это часть твоей работы. Покрывать и отлаживать, ведь отладка - это часть разработки. Разработчик сам должен думать о том, что будет, если в метод аргументом вдруг придёт null, если запрос ничего не вернёт, если список будет пустым, не произойдёт ли выхода за пределы коллекции и прочее. Думать и прогонять такие варианты либо предусматривать алгоритм так, чтобы исключить их совсем. И покрывать свой код тестами. Или ты думаешь, что при разработке новой фичи можно написать код на от##бись, а если не прокатит, то тогда исправлю? В этом случае тестировщик должен проанализировать ТЗ к методу, проанализировать логику работы твоего алгоритма, выявить возможные узкие места, придумать тестовые ситуации, при которых алгоритм поведёт себя неверно и со всем полученным набором вернуть задачу тебе на доработку. Тогда такого тестировщика проще сразу вместо тебя посадить писать код, ты не находишь?

Да при желании можно выучиться и вообще без джавараша, суть не в этом. Я, если честно, не особо понимаю, как можно подогнать решение под тесты. Тесты же для этого и пишутся, что если какой-нибудь из них падает, ты смотришь, какой именно упал, и пытаешься отладить функцию/класс и т.д. так, чтобы он не падал. Подгонка решения под тесты не является жульничеством или простым путем. Тебе же все равно нужно свое решение изменить так, чтобы все кейсы отработали. Но, возможно, я чего-то не понимаю.

vk чуть выше как-раз дал отличный развернутый ответ в разделе нравоучений) зная все возможные тестовые данные - не приходится задумываться о том, что что-то может пойти не так. а значит у вас не вырабатывается привычка учитывать возможные проблемы, которые могут вылезти при таком решении, и возможно лучше решить немного по-другому. не будет привычки сразу же учитывать граничные случаи (ну там а что будет если тут прилетит 0, а что если Integer.MAX_VALUE, а что если null, а что если отрицательное число), итд. так что да, если человек привыкнет постоянно писать код не такой, который будет оптимальным, или удобным и поддерживаемым, а такой, который просто проходит тесты - то это будет плохой специалист

Только тесты не охватывают все кейсы, тестов ограниченное количество. Если тебя попросят написать функцию, которая проходит через 2 точки 0,0 и 1,1 - ты можешь и y=x и y=x^2 написать, но верный ответ будет только один. Просто тебе дали мало точек, чтобы точно выбрать нужный вариант. Так же и с тестами, можно просто написать кусок, который удовлетворит всем тестам, которые есть, но по сути своей будет неправильным, любой шаг в сторону от теста - и будет ошибка. Выполнение тестов не является 100% гарантией того, что ты все сделал правильно. Чтобы минимизировать погрешность, от тебя и скрывают тестовые данные, чтобы ты пришел к теоретически правильному способу решения. Вот представь, что у тебя такие тесты: 3 2 1 0 e 4 3 1 -2 p 12 -2 3 1 privet Тут везде ответ 1, но это не значит, что будет правильным написать

System.out.print(1);

Тесты - это необходимое условие, но не достаточное. Если они не проходятся - точно неправильно, но если они проходятся - есть шанс, что все равно сделано неверно. Обычно, конечно, тесты не делают такими, как в моем утрированном примере, но подогнать решение под тесты вполне реально, при этом оно будет верно математически (результат совпадает с ожиданием), но ошибочно логически

Если я не ошибаюсь, то можно попробовать вывести в консоль args, и там должно быть условие теста

1 и 2 пункты - это не ошибки, ты сам вставил пункт из требований, где написано, что этот кейс можно не обрабатывать. "Если введено меньше двух целых чисел, то такую ситуацию обрабатывать не нужно, а программа может быть завершена с ошибкой." Т.е. я могу их инициализировать сразу двумя чтениями чисел с консоли, т.к. по условиям разрешается такой сценарий.

Успехов. Я тебе написал что в твоем коде не так :) Хочешь - дальше натягивай сову на глобус.

Ну справедливости ради "обрабатывать не нужно - твой код вылетит с исключением" противоречия не содержит. "Обрабатывать не нужно", значит такая ситуация исключена внешними факторами (api, вызывающими методами, тестами), другими словами таких тестов не будет. Можно выбросить исключение, можно упасть с нпе, можно зависнуть в ожидании третьего числа, можно выдать какой-то ответ, который не будет верным в виду отсутствия верного ответа. "Обрабатывать не нужно", значит действительно обрабатывать не нужно и проверяться это не будет. Что, конечно, не отменяет дыр в последующем алгоритме.

Да понятно что можно не обрабатывать, здесь скорее вопрос подхода. Рано или поздно человеку придется работать с кодом где нужно будет своей головой продумывать и отлавливать корнеркейсы, в том числе NPE, и другого рода исключения. Имхо, лучше такую привычку завести пораньше :)

Только если ты нажмешь на кнопку "показать верное решение", появится код, где первые два значения инициализированы значениями с консоли.

Верное не значит единственно верное. Вот тебе один из вариантов:

public static void main(String[] args) {
    Scanner scanner = new Scanner(System.in);
    int counter = 0;
    int min = Integer.MAX_VALUE;
    int secondMin = Integer.MAX_VALUE;
    while (scanner.hasNextInt()) {
        int nextInt = scanner.nextInt();
        counter++;
        if (nextInt < min) {
            secondMin = min;
            min = nextInt;
        } else {
            secondMin = nextInt;
        }
    }
    if (counter > 1) {
        System.out.print(secondMin);
    }
}