оптимизировать код

А что оно делает?

неочевидно?

если про суть - юнит-тесты, тестирую метод на полном диапазоне значений

Ну можно рекурсией запилить. Цикл в метод, передавать в него начальные данные плюс список x1..xN из стека вызовов.

Возьми какой-нибудь клон QuickCheck для java.

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

Fors.for3(myCollection,(x1,x2,x3) -> /* шота */);

функции forN сгенерить руками, для N от 1 до 255.

Перепилить функцию или разбить на несколько поменьше.
Кода аргументов >3 уже стоит задуматься.

Генерация перестановок

никак, а зачем оптимизировать юнит тест?

никак, а зачем оптимизировать юнит тест?

+

Если тебе надо А*А*А вызовов, тебе придется сделать А*А*А вызовов.

Только здесь нужны размещения с повторениями, судя по коду, а перестановка это без повторений.

A*...*A вызовов не изменятся, изменится убогонький стиль их написания. прикручиваю for в рекурсивном методе, выглядит вроде как получше

изменится убогонький стиль их написания

Я множество всяких комбинаций макросами генерю в сишечке, когда надо в тесте покрыть.

в жабе нет макросов, иначе бы как два пальца :(

http://habrahabr.ru/post/240811/

Примерно так: n - количество тестов.

for (int i = 0; i < N; i++) {
    func(randomX1, randomX2, ..., randomXN);
}

в жабе нет макросов

public static void main(String[] args) {
     String code = 
         "for (X x1: A)"+
             "for (X x2: A)"+
              ...
                 "for (X xN: A)"+
                     "func(x1, x2... xN);";
     Files.write(Paths.get("./target/gen-src/fors.java"), code.getBytes());
}

и да, у Maven есть фаза generate-sources. На которой кроме собственно создания сорцов можно запустить и maven-compile-plugin. Если не хватит этого (например, надо как-то хитро подчищать за собой), можно там же запустить groovy plugin или ant plugin, и там сотворить любую магию. Так что можно сравнительно просто генерить произвольное количество говна, любого сорта и в любом месте.

Гм, так и весь проект можно писать на нормальном языке (С++ с макросами), который потом генерирует нормальный Java-код! Как я раньше не догадался.

смищно.

Примерно так: n - количество тестов.

нет, нужен гарантированный обход всего диапазона

ну, у нас когда-то мавеном нереальные тонны кода на джаве вручную генерились, совсем не смешно это дебажить, но работу выполняет

так и весь проект можно писать на нормальном языке (С++ с макросами)

мне кажется, ты в этой фразе оговорился как минимум дважды

Лучше тогда gradle взять, там такие вещи намного более органично делаются.

Если закрыть глаза на то что gradle тормоз и глюкалово (во всяком случае, в android-варианте).

если там что-то типа

void func(X... args)

верхний пост с 133 лайками

http://stackoverflow.com/questions/16775197/building-and-running-app-via-grad...

больше всего помогает org.gradle.daemon=true, и покупка SSD и процессора i7

но мне почему-то мавен больше нравится, например если надо будет писать тулзу для анализа билд-файлов, для мавена это гораздо проще

юнит-тесты, тестирую метод на полном диапазоне значений

Цитирую Боба Мартина: «Тесты должны выполняться быстро, не более десяти минут на запуск и прохождение».

Короче говоря, с твоими тестами что-то не так.

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

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

больше всего помогает org.gradle.daemon=true, и покупка SSD и процессора i7

Да вот да, знаю я это. Но всё равно ситуация удручающая. Раньше я мог очень легко работать на макбук эйре с 4 гигами, а теперь он кажется тормозным мамонтом из прошлого века.

А если результатом будет поток из пар (комбинация, код возврата теста) сможешь потом отфильтровать его по нужным кодам возврата, например все сбойные.

Почему бы просто не купить новенький топовый макбук?

Использовать LINQ... То есть, я хотел сказать, Stream API. Метод forEach твой выбор.

http://docs.oracle.com/javase/tutorial/collections/streams/

http://learn.javascript.ru/array-iteration

Нужно сделать cartesian product A самой с собой N раз, вот функция для Sets из гуавы: http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/coll...

Код будет выглядеть приблизительно так:

for(List<X> comb: Sets.cartesianProduct(A, A, A, ..., A)) func(comb.get(0), comb.get(1), ..., comb.get(N));

Челу нужны комбинации а не перестановки, твое решение не выдаст 1,1,1,1,1 например.

Сначала нужно понять - что это за конкретный код и что конкретно он делает.

А дальше курить http://habrahabr.ru/company/intel/blog/106082/

https://ru.wikipedia.org/wiki/Цикломатическая_сложность

А дальше вопрос к «качеству кода»(С)(ТМ).

он кажется тормозным мамонтом из прошлого века.

mono

В Вашей подписи есть ответ на Ваш риторический вопрос.

Пишу с Acer 5742G, на котором весьма шустро крутится GXT/Spring/Hibernate приложение.

Естественно, на нормальном enterpriZe языке программирования, а не на поделии от Мигеля Икасы.

Я тоже пишу на нормальном enterpriZe языке программирования, потому что я уже около 5 лет ведроид-девелопер, а мой ник – это просто ник.

Про GXT/Spring/Hibernate ничего сказать не могу, но уверен, что gradle на Acer 5742G будет работать так же «быстро» как и на моём macbook air.

Тесты должны выполняться быстро, не более десяти минут на запуск и прохождение

Один тест, или все?

Делай вызов func два раза, что б наверняка.

Челу нужны комбинации а не перестановки, твое решение не выдаст 1,1,1,1,1 например.

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

Один тест, или все?

Все тесты.

И каким образом это достижимо, если кодовая база проекта непрерывно растёт? В проекте на пару гигов исходников тесты могут идти час.

Для каждого модуля - свой набор тестов. Запускать помодульно.

Тогда все тесты в сумме будут больше 10 минут, о чём я и спрашивал. Неважно как запускать, всё равно запускать на каждом этапе нужно все тесты.

Что может нищеброд из убогой, дикой масквашки знать про enterprise? Такого лоха до компаний из ftse100 и близко не допустят.

Нормально работает. i3-380M. 6GB RAM.

Я не трачу деньги на быстро устаревающие технологии.

У меня другие ценности - как здесь показано -

http://lowres.cartoonstock.com/music-wifi-hi_fi-record_player-vinyl-seven_inc...

(Кто из показанных на рисунке персонажей более счастлив?:))

3 вложенных for

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

И да, за функции/методы с более, чем двумя, параметрами тоже сжигать надо - рефактори программу так, чтобы у тебя функции максимум два параметра имели (и никаких boolean-параметров! Один метод должен выполнять строго одно действие, а не представлять из себя лапшу с кучей ифов!). Выноси функционал в несколько различных методов.

и никаких boolean-параметров!

А булеан параметры чем провинились?

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

Булевы параметры обычно юзают, чтобы превращать нормальные методы (или функции, если мы о C говорим, ЯП тут не важен, важен принцип) в нечто подобное:

Псевдокод:

void superCoolMethode(int num, bool param) {
  if (param) {
     someAction(num)
     …
     over 9000 lines
  } else {
      otherAction(num)
      …
      over 9000 lines
  }
}

То-есть, метод выполняет два различных действия, в зависимости от переданного boolean-параметра. А если этих булевых параметров два, то мы имеем 4 разных действия. А если три, то все 8. А это не дело - метод должен выполнять только одно действие.