Dane testowe

Wszystkiemu winna szuflada

Tworząc projekty do szuflady może pojawić się problem, skąd i jak wygenerować zawartość. Chociaż kilku użytkowników, chociaż kilka wpisów, kilka słów, dzięki czemu można zobaczyć jak system będzie wyglądać gdy ktoś będzie z niego korzystać.

Pisałem wcześniej o generatorze losowych danych Faker (http://jaroslawstadnicki.pl/2015/04/generator-danych-faker/). Nadal z niego korzystam, dzięki temu w stosunkowo krótkim czasie byłem w stanie wygenerować całkiem sensowną, pod względem ilości – nie jakości, bazę danych na której pracuję.

Tests controller

W projekcie posiadam specjalny kontroler, z którego zarządzam generowaniem losowych (lub pseudo losowych) danych.

2016-04-24 14_12_58-title

Zrzut z kontrolera tests i widoczne dostępne opcje. Widać, ze mogę tworzyć użytkowników, duplikować kanały, tworzyć subskrypcje, dodawać elementy do przeczytania, generować wydarzenia, czy wreszcie naprawiać problemy, które wynikają, że mojego lenistwa.

Co mi to daje? Otóż wygenerowałem sobie bazę, która aktualnie ma 1.1 gigabajta, a składa się na to:

Co Ile
EventRssVieweds 2102
FeatureRequests 98
RssChannels 6012
RssEntries 211002
RssEntriesToRead 177642
SocialLogins 2
Users 2097
UserSubscriptionEntryToReads 0
UserSubscriptions 0

Co w tym ciekawego? Otóż mam tylko jednego aktywnego/prawdziwego użytkownika (to ja – taram), reszta to wytwór wyobraźni fakera. Część kanałów została zaimportowana z mojego feedly, inne natomiast to duplikaty, o zmienionej nazwie, lub zaciągnięte gdzieś z dostępnych list rss. O FeatureRequests pisałem wcześniej: http://jaroslawstadnicki.pl/2016/04/feature-request-jak-to-ugryzc/. Zostają już tylko jakieś subskrypcje kanałów dla sztucznych klientów, ich sztuczna aktywność (EventRssVieweds) oraz ich pojedyncze wpisy, które powinni przeczytać. Na koniec to z czym walczę aktualnie, czyli subskrypcje dla aktywności użytkowników.

Co z tego dla mnie

Po co to wszystko? Wcześniej pisałem o obowiązkowej konfiguracji entity framework (http://jaroslawstadnicki.pl/2016/03/entity-framework-obowiazkowa-minimalna-konfiguracja/) gdzie w komentarzach były różne zdania na ten temat, natomiast padło stwierdzenie, że nigdy nie pojawi lub nie powinien pojawić się w kodzie taki kod:

db.MojeEncje.ToList()

I teraz, taki kod nie pojawi (nie powinien) się pojawić gdy masz danych dużo. U mnie gdy robiłem wpis było tego malutko. Gdy wygenerowałem ich trochę, taki zapis zaczyna dopiero nabierać znaczenia. To nie znaczy, że wtedy nie byłem świadomy konsekwencji, wtedy mogłem sobie na to jeszcze pozwolić. Teraz powoli zaczyna mnie to boleć. Ale jeszcze nie na tyle, aby to zmieniać.

To dzięki takiej ilości danych, zaczynają się pojawiać problemy o których się nie myślałem wcześniej: stronicowanie, filtrowanie, projekcja danych na poziomie orm. czy sam orm jest mi potrzeby, czy automapper da rade, czy tyle warstw jest mi potrzebnych,… inne do których jeszcze nie doszedłem. Znowu część rzeczy wynikać będzie z chęci poprawy wydajności samej aplikacji, inne z użyteczności aplikacji.

O co mi chodzi?

Wygenerujcie sobie dane testowe, niech to będzie Jan Kowalski1234123141231231, niech czyta Lorem Ipsum12312312312, po tysiąc razy, niech zapcha bzdurami waszą bazę danych, albo niech nie posiada nic, taki null-user-object, albo niech posiada jeden wpis – bo nigdy nie wiecie, kto będzie waszym klientem. Zróbcie bazę danych która ma kilka giga i zobaczcie jak sobie radzie gdy danych jest więcej aniżeli kilka.

5 thoughts on “Dane testowe

  1. Świetny wpis z morałem. 🙂

    Ja od siebie mogę polecić inną bibliotekę do generowania danych testowych – AutoFixture. Może nie potrafi tego, co Faker, ale jest dość łatwo rozszerzalna.

    P.S. Mnie się zdaje, czy w tym poście o Fakerze rozjechały się style od wstawki kodu?

  2. Tak, masz rację – AutoFixture potrafi wstrzykiwać do metody testującej potrzebne w niej obiekty. Ale także dane testowe potrafi generować całkiem sprytnie i głównie z tej możliwości korzystam.

Dodaj komentarz