Последовательное выполнение

Тредс

Это я понял, но можно чутка посодержательнее?

Что-то ты не так делаешь. Каждый тест должен быть независимым от других. Иначе какой вобще смысл в тестах? Если три теста не независимы друг от друга, то сделай один вместо трех. Или добавь метод который будет подготавливать environment.

Если что я давно уже не писал на джаве.

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

Очень не хотелось бы делать из метода свалку

можно сделать вспомогательные методы

Можно вообще оставить один тестируемый метод, свалив туда все остальные. Получается последовательно, правда неинформативно: будь хоть 100 тестируемых функций, для системы всегда будет одна

Так сделай чтобы 3 теста не зависели друг от друга. Если входными данными для func2 являются выходные данные от вызова func1 - создай входящие данные вручную, без вызова метода func1.

Да, засунь все методы в один. Я уже комментировал этот вариант выше

Если у тебя упадет первый тест. То упадут и второй, и третий. Какой тогда смысл делать отдельные тесты если падать они будут вместе? Объедини в один тест, а чтобы не было свалки разбей на отдельные методы. Junit запускает тесты паралельно не просто так.

Можно вообще оставить один тестируемый метод, свалив туда все остальные

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

Ошибку и так покажет, просто так ещё и ткнет в конкретный метод, что позволит не скроллить каждый раз окно редактора с номером строки в зубах

Если каждый тест независим, то им не нужно выполняться последовательно.

У меня все тесты абстракционно принадлежат содержащему их классу (контейнеру). В моем случае все это слепое придерживание методолгии будет выглядеть примерно так:

class TestContainer
{
    @Test
    public void onlyOneMegaMethod()
    {
        // over 1000 lines
    }
}

Я в гробу видал такую автономность.

Ваши «претензии» на архитектурное качество тестирования были бы обоснованы, если бы я пытался, например, учинить последовательность отдельно взятого массива методов посреди какого-нибудь UserActions с дюжиной абсолютно разноплановых тестируемых процессов.

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

Всё хорошо. Только почитай мат часть по юнит тестиронию. Тебе намекают, а ты упрямишся.

Мне целый день намекают, что мои тесты - говно. В каком месте я упрямлюсь, когда ни одной ссылки на четко поставленный вопрос не прозвучало - разъясни, пожлуйста.. исправлюсь.

На форум прихожу только после нескольких часов гугления. Я не знаю, как можно реализовать поставленную задачу или покурить про неё, и пока ещё надеюсь, что кто-то подкинет ссылку или хотя бы развеет мои надежды угрюмым «нет, это нереально, onlyOneMethod only»

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

Второе, в вики по JUnit есть решение с порядком тестов для версии >=4.11: https://github.com/junit-team/junit/wiki/Test-execution-order Как работает показали тут: https://stackoverflow.com/questions/3693626/how-to-run-test-methods-in-specif...

Если ты можешь просестить функционал в последовательнить тестов, либо в одному громоздком тесте - ты что-то делаешь не правльно, пересмотри функционал, разнеси по расзным вспомогательным классам

Каждый метод, в идеале, должен выполнять только ОДНУ задачу. Я просто разгружаю метод, пытаясь не устроить из своей тестировочной конструкции одну большую выгребную яму, потому что «так принятно/написано в вики про юниты». Просто понимаешь, так бывает, что иногда надо не просто прогнать changepassword(), а, допустим, собрать плагин, перенести его в нужную диру, заинсталлить в браузер, попутно чекнув пути и результат деятельности этих подметодов, почему я должен устраивать помойку в своем, специально для этого выделенном классе - классе браузера? Или настрогать под каждую операцию по ещё одному классу: class ConvertPluginToExtension, class InstallPluginToProfile? К тому же их тоже потом придется выстраивать друг за дружкой, зависимость-то некуда не делась от этого. Или будет лучше засадить их все в один метод? А имя какое выберем, наверно convertPluginToExtensionAndThenInstallPluginToProfileAndRun?

Вообще то да, насоздавать кучу классов и так поназывать)))))

Для таких целей тебе может быть удобнее научиться польщоваться огуречными тестами, как нить потыкай на досуге http://cukes.info/

Ладно, я сдаюсь, поступлю как сраный быдлокодер белый человек: буду запускать подметоды из одного тестируемого; так и быть, система меня сломала, в рот ей пятки

подожди, а чем тебе непоравилось с @FixMethodOrder(MethodSorters.NAME_ASCENDING) ??

Тесты стартует по очереди, вот только все так же в тучу потоков, а мне нужно последовательное и томное выполнение КАЖДОГО теста.

:)

Прочитай документацию! Про Loader, Runner и Suite.

Через собственный раннер было изначально неинтересно такое делать