О применении рефлексии в тестировании и не только

[zagayevskiy]

Даже если не говорить о полезности и правильности таких "тестов", почему бы просто не пропихнуть тестируемый инстанс через фабричный метод? Кода было бы даже меньше, и без рефлексии.

[PqDn]

так я понимаю в этом случае придется что-то писать в наследных тестах? Правильно я вас понял?

[zagayevskiy]

А здесь не надо?

[PqDn]

нет, если функционал не расширять

[zagayevskiy]

MergeSortTest extends ISortTest

A это как же?

[PqDn]

Я имел ввиду в теле класса ничего писать не надо

[zagayevskiy]

А где плюс этого-то? Что не надо писать, одну строку? Серьёзно? Унесите это с хабра и закопайте где-нибудь.

Простейший пример — в конструктор каждой конкретной реализации нужно передать некие аргументы, всегда разные. Что делать будете?

[PqDn]

Это очень простой пример. Я всего лишь хотел показать как для таких ситуаций использовать рефлексию…
Поверьте можно оч. крутые вещи делать таким подходом

[PqDn]

Простейший пример — в конструктор каждой конкретной реализации нужно передать некие аргументы, всегда разные. Что делать будете?

Да вы знатный троль

[zagayevskiy]

Эээ… Я тролль?..

[javaevangelist]

А почему просто нельзя то вернуть дата провайдер с имплиментациями алгоритмов сортировок и в одном тесте их все прогнать? Еще уродливый и не эффективный стрим в конструкторе.

[PqDn]

нет там стримов

[PqDn]

Представте, что таких классов несколько сотен

[javaevangelist]

и что? В вашем случае 100 дочерних пустых классов будет, нахер бы они нужны были? Просто мусор

[aleksandy]

Всё решается гораздо проще и без всякого наследования.

JUnit4

@RunWith(Parameterized.class)
public class ISortTest {

    private ISort sortAlgorithm;

    public ISortTest(ISort sortAlgorithm) {
        this.sortAlgorithm = sortAlgorithm;
    }
    
    @Test
    public void sort() {
        assertNotNull(sortAlgorithm);
        int n = 10000;
        int[] ints = new Random().ints().limit(n).toArray();

        int[] sortInts = Arrays.stream(ints)
                .sorted()
                .toArray();

        int[] testSotrInts = sortAlgorithm.sort(ints);
        assertArrayEquals(sortInts, testSotrInts);
    }

    @Parameterized.Parameters
    public static Collection<Object[]> data() {
        return Arrays.asList(
            new Object[] { new BubleSort() },
            new Object[] { new MergeSort() }
        );
    }

}

JUnit5

class ISortTest {

    @ParameterizedTest
    @MethodSource("data")
    void sort(ISort sortAlgorithm) {
        assertNotNull(sortAlgorithm);
        int n = 10000;
        int[] ints = new Random().ints().limit(n).toArray();

        int[] sortInts = Arrays.stream(ints)
                .sorted()
                .toArray();

        int[] testSotrInts = sortAlgorithm.sort(ints);
        assertArrayEquals(sortInts, testSotrInts);
    }

    static Stream<Arguments> data() {
        return Stream.of(
            Arguments.of(new BubleSort()),
            Arguments.of(new MergeSort())
        );
    }

}

[javaevangelist]

Дак вот! Я о том же, и без рефлексии, по крайней мере самопальной

[PqDn]

Ну тут всего лишь пример, так получилось что для тестирования…
Пример показывает как использовать рефлексию для работы с дженериками.

Если брать JUnit, то там внутри очень много рефлексии.
Если взять спринг, то там очень много рефлексии.

Всё это удобно и классно

Но чтобы сделать что-то подобное самому, нужно понимать как и самому сделать такое.

[javaevangelist]

Тогда надо было назвать статью «Как работать с generics через reflection api»