Generowanie danych do testów

Chcę wygenerować dane do testów, których będę używać podczas pisania frontu. Jak to najlepiej zrobić? W EF Core jest HasData, ale w dokumentacji piszą, że do danych testowych lepiej tego nie używać, bo ma za duże ograniczenia. Piszą też, że:

The seeding code should not be part of the normal app execution as this can cause concurrency issues when multiple instances are running and would also require the app having permission to modify the database schema.

Depending on the constraints of your deployment the initialization code can be executed in different ways:
Running the initialization app locally
Deploying the initialization app with the main app, invoking the initialization routine and disabling or removing the initialization app.

1. Tak to się robi? Tworzy się osobną aplikację konsolową, która służy do inicjalizacji bazy?
2. Czy dane do testów integracyjnych i dane, które idą na front podczas developmentu, powinny być różne?

Zalezy ile tych danych chcesz wygenerowac, jesli dziesiatki tysiecy to lepiej unikac hasdata i napisac generowanie danych w t-sql. Ja do testow integracyjnych uzywam in memory i dane tam leca z hasdata.

Raz mialem za zadanie wygenerowac 400 tys rekordow. Jedyne rozwiazanie to plik sql dolaczony do migracji

@szydlak: Jeśli wdrażasz aplikację, to po prostu generujesz skrypt SQL migracji i wywalasz te dane z hasdata? I czego używasz do generowania tych danych? Bogusia?

Jeżeli dane są nie jakoś mocno złożone, to forki po wstrzyknięciu się w Startup aż się nie uzbierają sensowne dane.

Jeżeli są, to kradnę bazę z proda po anonimizacji :D

Jeżeli faktycznie integracyjny, to on działa na pustej bazie i ma sobie wygenerować dane przy realizowaniu flow lub dostaje coś "z ręki" aby móc iść dalej.

Ale ludzie piszą, że w Startupie nie powinno się takich rzeczy robić, bo on służy do konfiguracji serwisów i pipeline requestów.

Na szybko zaklepałem takie coś:

        public static void Main(string[] args)
        {
            var host = CreateWebHostBuilder(args).Build();

            var context = (ApplicationDbContext) host.Services.GetService(typeof(ApplicationDbContext));

            if (!context.Database.CanConnect())
            {
                context.Database.Migrate();
                TestDbInitializer.Initialize(context); // Baza do testów
            }
            
            context.Dispose();

            host.Run();
        }

Tak to ma wyglądać?

Ja ostatnio jeśli chodzi o testy integracyjne to korzystam z tego rozwiązania: https://docs.microsoft.com/pl-pl/aspnet/core/test/integration-tests?view=aspnetcore-2.2

A jeśli chodzi o dane to: To co jest w hasData pojawi się w np InMemory. A jak potrzebuje czegoś więcej to dodaje w projekcie testowym (Jest tam też przykład w tym linku z MS)

Generalnie moje testy integracyjne wyglądają bardzo podobnie do tego: https://www.codingame.com/playgrounds/35462/creating-web-api-in-asp-net-core-2-0/part-3---integration-tests

nobody01 napisał(a):

1. Tak to się robi? Tworzy się osobną aplikację konsolową, która służy do inicjalizacji bazy?

Zazwyczaj tak robię.

2. Czy dane do testów integracyjnych i dane, które idą na front podczas developmentu, powinny być różne?

Ja zazwyczaj używam oddzielnych baz do testów integracyjnych (i ją sobie tworzę na nowo dla każdego fixture).
Ale zdarzały mi się też takie projekty, w których baza jest jedna, na dodatek nigdy nic z niej nie było usuwane.

Do generowania danych używam AutoFixture. I tak mam masę customizacji, które są potrzebne w unit testach, więc mam jak wygenerować prawidłowe dane, które można wstawić do bazy. Ten Bogus może i fajnie wygląda, ale wydaje się słabo reużywalny i zbyt wiele trzeba konfigurować.