Stworzenie wewnętrznej bazy danych dla środowiska produkcyjnego

Mam pytania odnośnie baz danych dla różnych środowisk:

• Jaka baza danych dla środowiska produkcyjnego
• Jaka baza danych dla środowiska testowego Embedded In-Memory, a może po prostu jakiś Mock jak tak to dajcie przykład dla Springa Mock/Stub podajcie przykład mock'a stab'a wtedy? Chciałbym zwrócić uwagę: Gdy dodam użytkownika do bazy w profilu testowym, dla kolejnych testów musi on zostać przecież usunięty, żeby zachować zasady tworzenia testów, ale usuwanie go ręcznie jest zbyt niewygodne...
• Dlaczego po stworzeniu tego obiektu otrzymuje baze danych typu in-memory, zamiast embedded... jak to zmienić

 
    @Bean
    public DataSource dataSource() {
        return new EmbeddedDatabaseBuilder()
                .setType(EmbeddedDatabaseType.H2)
                .setName("test")
                .build();
    }

• Rozumiem, żeby uzyskać dostęp do bazy z zewnętrznego klienta muszę, uruchomić bazę embedded nie może to być In-Memory ?

Pozdrawiam

Przepraszam, to:

Jaka baza danych dla środowiska testowego Embedded In-Memory, a może po prostu jakiś Mock jak tak to dajcie przykład dla Springa Mock/Stub podajcie przykład mock'a stab'a wtedy?

Miało brzmieć tak:

Jaka baza danych dla środowiska testowego Embedded In-Memory, a może po prostu jakiś Mock/Stub jak to ostatnie podajcie jakiś przykład takiego obiektu imitacji

No i w temacie miało być środowiska testowego a pytanie o środowisko produkcyjne miało być pytaniem o środowisko developerskie, Przepraszam serdecznie, ale dzisiaj jestem lekko nieogarnięty.

Dziwne pytanie.
My na testowych stosujemy te same co na produkcjach.

Czemu chcesz mieć inne motory?

Widocznie mylę pojęcia jeżeli związane ze środowiskiem. Więc opisze to bez takich pojęć: chce wykonać testy jednostkowe dla repozytoriów. Do tego muszę mieć jakąś bazę danych, to ma być jakiś Mock ? raczej jest to nie wykonalne... Więc, testy jednostkowe raczej wywołam dla bazy typu embedded, jeżeli dodatkowo chce mieć dostęp do niej z zewnętrznego klienta ?

Środowisko QA pomyliłem ze środowiskiem dla testów jednostkowych, a testy liczą się jako środowisko developerskie tak ?

Testy jednostkowe nie wymagaja bazy, mockujesz zależności
Testy integracyjne baza danych taka sama jak na produkcji

A co ty chcesz testować w tych repozytoriach? Czy JPA dobrze pobiera dane? ;]

W sumie na razie korzystam z spring data JPA z automatyczną generacją repozytoriów, i wiem, że nie powinienem tego testować. Ale jak dodam własną metodę to chyba powinienem sprawdzić czy dobrze użyłem JPA, powiedzmy, że zrobię mały refaktor encji, i zapytanie będzie błędne. Jak mam mockować te zależności jak chcę przetestować działanie ORM'a mam zrobić Mock dla bazy i będzie przechowywać moje encje w postaci najzwyklejszych POJO jak wtedy przetestować moje zapytanie ?

Możesz w teście ładować sobie testowy spring context który ma datasource na jakąś bazę typu HSQL na której to sobie przetestujesz na przykład.

Mam tak:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = {WebConfig.class})
@WebAppConfiguration
public class TestUserRepository {

    @Autowired
    UserRepository userRepository;

    public void setUp() {

    }

    @Test
    public void userRepositoryIsNotNullTest(){
        Assert.assertNotNull(userRepository);
    }

    @Test
    public void findUserTest() {
        User user = userRepository.findOne("User");
        Assert.assertNotNull(user);
    }

    @Test
    public void userNotExistsTest() {
        User user = userRepository.findOne("THISUSERNOTEXISTS12321331");
        Assert.assertNull(user);
    }
}

Mówisz, że to dobre rozwiązanie ? (poza tym, że sprawdzam operacje find)

No, ale wtedy pojawia mi się drugi problem, gdy próbuje się dostać do bazy:

 
@Profile("dev")
@Configuration
public class DataSourceDev implements DataSourceResolver{

    @Bean
    public DataSource dataSource() {
        return new EmbeddedDatabaseBuilder()
                .setType(EmbeddedDatabaseType.H2)
                .setName("test")
                .build();
    }
}

Tzn. Chce dostać się do bazy z klienta zewnętrznego, ale spring tworzy mi bazę typu in-memory, mimo obiecanej Embedded, dobrze rozumiem, że z zewnątrz mogę się dostać tylko do Embedded ?

No i jest jeszcze problem związany, z niezależnościa od siebie testów jednostkowych dane powinny być usuwane z bazy testowej po zakończonym teście, aby kolejny test nie kolidował z poprzednim testem.

Dobra, chyba wymyśliłem rozwiązanie drugiego problemu, który był chyba dość prosty

 
    @After
    public void tearDown(){
        userRepository.deleteAll();
    }

Dodatkowo, przestane trzymać insert into w zewnętrznym pliku import.sql które jest wywoływany przez hibernate i dodam je do

 
@Before    
public void setUp() {

    }

Pozostaje poprzedni problem, i czy to rozwiązanie jako całość jest satysfakcjonujące w projektach ?

Idea jest ok ale taki test:

    @Test
    public void findUserTest() {
        User user = userRepository.findOne("User");
        Assert.assertNotNull(user);
    }

Jest idiotyczny i za commitowanie takiego testu byłyby 3 lata kamieniołomu. Co ty tutaj testujesz? o_O Czy Spring Data działa? Czy JPA działa? Czy baza danych działa? To jest przykład kiedy ktoś nie rozumie co chce przetestować i po co.
Ten setup może się przydać jeśli odpalasz jakieś custom query i chcesz przetestować czy jest poprawne.

Shalom, wiem o tym, napisałem:

Mówisz, że to dobre rozwiązanie ? (poza tym, że sprawdzam operacje find)

Zdaję sobie sprawę, że testowanie automatycznych repozytoriów to robota twórcow springa, moim zadaniem jest przetestowanie custom queries jak to nazwałeś. To był tylko taki przykład, czy to by tak wyglądało jakby metoda findOne() była metodą zaimplementowaną przeze mnie. Zastanawiałem się, jak to będzie wyglądać gdy będę musiał zaimplementować własną metodę dla automatycznych repozytoriów.
Hmm rozumiem,że informacji o zmianie bazy typu In-Memory na Embedded w springu będę musiał szukać na własną rękę:P ? Ok to problem, z którymś sobie jakoś poradzę. Dzięki za pomoc.