Testowanie singletona

Odpowiedz Nowy wątek
2015-01-03 13:00
Tgc
0

Tworze zadanie na platforme z roznymi zagadkami programistycznymi (kiedys reklamowalem ten serwis w dziale OT). Wymyslilem sobie, zeby uzytkownicy zaimplementowali bezpiecznego watkowo singletona z leniwa ewaluacja.

Przykladowo zle zaimplementowany przez uzytkownika singleton moze wygladac tak:

    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();}
        return instance;
    }

A moj test jednostkowy weryfikujacy rozwiazanie tak:

public void testUnique() throws ExecutionException, InterruptedException {
        final ExecutorService pool = Executors.newFixedThreadPool(2);
        final Future<Singleton> value1 = pool.submit(() -> Singleton.getInstance());
        final Future<Singleton> value2 = pool.submit(() -> Singleton.getInstance());
        assertEquals(value1.get(), value2.get());
    }

Oczywiscie aby test sie wywalil musi byc powtorzony wiele razy. Idea nie jest najlepsza bo mimo wszystko test jest niedeterministyczny, ale lepszego pomyslu nie mam. Problemem jest jednak odpalenie go n razy. Uzycie junitowego @RunWith(Parameterized.class) nie zda egzaminu, poniewaz kazde odpalenie testu powinno byc w osobnej VM. Inaczej w przypadku gdy pierwsza proba przejdzie pomyslnie, reszta nie ma szans sie wywalic. Normalnie moglbym sobie poradzic przy pomocy parametru fork z ant-junit tudziez innych bibliotek wspomagajacych junita, ale na platformie mam tylko JUnit 4.11.

Jednym pomyslem ktory mam jest zaimplementowanie metody reset wykorzystujac refleksje wykonywanej po @After, ktora bedzie ustawiac pole przechowujaca instancje singletona na nulla. Problem w tym, ze niektorzy uzytkownicy moga miec rozne szalone pomysly na zaimplementowanie testowanego singletona i niekoniecznie taka zmienna w ich kodzie byc musi.

Pozostało 580 znaków

2015-01-03 13:06
0

Nie zastanawiałem się długo, ale na mój gust nie da się deterministycznie przetestować niedeterministycznego kodu w ogólności :)

Pewnym rozwiązaniem byłoby wymuszenie wstawienia długiego sleepa w konstruktor singletona. Mógłbyś to zrobić tak, że np singleton musi dziedziczyć po jakiejś klasie lub przyjmować jakąś tam funkcję do odpalenia podczas konstruowania obiektu. Załatwiłoby to tę najprostszą implementację leniwego singletona, ale bardziej zaawansowane wadliwe singletony dalej by pewnie przechodziły w 99.9999... % przypadków.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 1x, ostatnio: Wibowit, 2015-01-03 13:07

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0