A CI/Unit test megoldásotok csatlakozik SQL adatbázishoz? (SQLite is számít)

Programozás

.

Igen, egy kézzel karbantartott .sql séma része a reponak, és azalapján futnak a tesztek
8% (14 szavazat)
Igen, ORM generálja ki a sémákat, és azalapján futnak a tesztek
8% (15 szavazat)
Igen, a kézzel megírt sémaváltozásaink helyessége is a tesztelés része
6% (11 szavazat)
Nem, mockoljuk az amúgy SQL-ből várt adatszerkezeteket
9% (16 szavazat)
Nem, csak az adatbázissal nem dolgozó funkciókra írunk tesztet
3% (5 szavazat)
Nem, mert nem használunk RDBMS-t
7% (13 szavazat)
Nem, mert nincsenek unit tesztjeink
18% (33 szavazat)
Nem vagyok programozó
41% (73 szavazat)
Összes szavazat: 180

( trey | 2019. 10. 24., cs – 10:39 )

Hiányolom a "Fogalmam sincs, mert programozóként azt sem tudom, hogy eszik-e vagy isszák ezt az Unit-izét" opciót.

--
trey @ gépház

( carlcolt | 2019. 10. 24., cs – 17:56 )

Leginkabb ket fejlodesi ut van:

4/5 --> 2
Es
4/5 --> 1 --> 3

Nekem a 3. opcio a kedvencem, remeltem, hogy elol fog allni. Nem szeretem, amikor ORM-re bizzak a migraciot.

Szoval a lenyeg a 2. vs 3. opcio eredmenye, esetleg iranyt tekintve az 1+3 vs 2

6. opciotol lefele mindegy, nem erintettek a szavazasban.

( cherockee v | 2019. 10. 24., cs – 18:00 )

Egyik legmegosztottabb szavazás eddig személyes emlékeim alapján, főleg ha kiveszem a nem érintetteket (nincs RDBMS, unit test vagy programozói tevékenység, ezek az opciók nem biztos, hogy kellenének ide).

Kellenek, kulonben kamuszavaznanak a userek. Mondjuk lehet igy is, tobbszor feltunt, hogy van egy keves user aki csakazertis a legfelsot nyomja, mert konnyebbnek tartja azt a UX-et, mint az eredmenyek ful megkereseset.

Az meg mar velem is elofordult, hogy ugy szavaztam, hogy a lenti opciokat nem olvastam el.

Gondolkodtam mar azon is, hogy legfelulre teszem a "nem vagyok erintett a szavazasban" gombot. Csak igy se biztos hogy Trey kiteszi oket vagy akar at is rendezheti (ezt nagyon ritkan szokta). Igy meg mar lehet a Feng Shuijat is megzavarnam.

Amugy a legtobb nemerintett szimplan nem szokott szavazni, hasonlitsd ossze mas, kevesbe szakmai szavazasok szavazatszamaval az itteni szavazatok szamat.

> Mondjuk lehet igy is, tobbszor feltunt, hogy van egy keves user aki csakazertis a legfelsot nyomja, mert konnyebbnek tartja azt a UX-et, mint az eredmenyek ful megkereseset.

ebbol a nehany idiotabol par meg be is jelentette, hogy igy tesz, nem erdemes fennakadni rajta, szerencsere a tobbseg ert magyarul

( Nyosigomboc v | 2019. 10. 25., p – 00:26 )

Legutolso olyan nem-hobbi projectem, amiben volt RDBMS, az tavkozlesi kutyukbol szarmazo mindenfele adatot (sebesseg, csomagvesztes statiszika, meg effelek) tarolt benne, es a kutyuk nelkul kb. ertelmetlen lett volna mindenfele teszt.
Ahol komolyabban teszteltunk, ott meg nem volt SQL.

Hobbiprojectjeim meg ritkan olyan bonyolultsaguak - SQL megletetol fuggetlenul - hogy unit teszteket irjak.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

( enpassant v | 2019. 10. 25., p – 06:55 )

A következő kettőn kívüli mind jó megoldás szerintem:
2. "Igen, ORM generálja ki a sémákat, és azalapján futnak a tesztek"
4. "Nem, mockoljuk az amúgy SQL-ből várt adatszerkezeteket"

Megjegyzés:
- ORM használata nem jó! Ha használunk ORM-et, akkor jó a 2. megoldás használata is.
- Ne Mock-oljunk! Ugyanarra való az 5. pont is: "Nem, csak az adatbázissal nem dolgozó funkciókra írunk tesztet", ha jól szervezzük a kódunkat.

Én a 2. és 4.-et vártam (várom) befutónak, mert azok az Enterprise megoldások. ;-)

Hogy micsoda? Van fogalmad mit takar a unit test? Ezek szerint nincs. DB kapcsolatra integráció tesztet írunk a unit test-ben meg mindent is mockolunk ami külső, hisz csak az egység funkcionalitása érdekes.

Unit test - Integration test - Acceptance tests

Mind a három szint elvárt.

return resolveUser("zeletrik").map { it.sign }

CI-rol szolt a szavazas, a "unit test" segedfogalom volt azoknak, akik meg csak arrol hallottak.

Egyebkent szerintem a "unit test" szo szerinti ertelmezese overrated, az integration test pedig underrated. Inkabb valasztanek egy olyan projektet karbantartani, ami az ugyanolyan magas test coverage-et integration test-ekbol erte el, mint egy olyat, ami unit test-ekbol. Unit test szerintem 10 fuggvenybol kb 1-hez kell, a tobbi 9-et integration test-kent van ertelme egyutt megnezni, hogy mukodik-e, mert a unit test kb 1 == 1 komplexitasu lenne.

De ez a velemenyem eleg nepszerutlen, tudom.

( visko | 2019. 10. 25., p – 08:18 )

A unit testeknek nevükből adódóan nem lenne szabad csatlakozzanak DB-hez, azok a component test-ek kellene legyenek. De a kérdést értettem és azért jegyeztem meg ezt, mert sok helyen koncepcionálisan rosszul írják ezeket az alacsony szintű teszteket.

Így van, Unit tesztnél kvázi csak a 4. és 5. pont jó (szerintem csak az 5. ;-)
CI-nél persze más a helyzet, ott futhat unit teszt is, integrációs teszt is.

Azonban van egy homályos mezsgye, a memória adatbázisok, amik az adott gépen, az adott program keretein belül futnak.
Én ezeket is unit tesztnek hívom, mert kielégíti az általam fontosnak tartott F.I.R.S.T. elvet.

( uid_21239 | 2019. 10. 25., p – 11:17 )

Mi a kulonbseg az 1-es es 3-as kozott?

1 - valamikor 2 eve csinaltunk egy .sql-t, migraciokat azota futtatgatunk kezzel. Ha mar nagyon kell neki egy uj oszlop/tabla belepaste-eljuk kezzel

3 - van egy (nem ORM-re, hanem text based CREATE TABLE-okre epito) migracios script, es ha az hibat talal egy migracioban, a CI run failed

Tehat az 1-esnel atmehetnek a tesztek, mikozben te mar nem tudod a lokal copy-dban lefuttatni a migraciokat. A 3-asnal ha lefutnak a tesztek, te is tudsz adatbazist frissiteni a lokal copy-dban.

( melon | 2019. 10. 26., szo – 19:22 )

En vegul azt valasztottam, hogy "nem, mert nem hasznalunk RDBMS-t".

De azert vakartam a fejem, hogy ha hasznalnank, akkor vajon mit akarhatott az OP a kerdessel. Szerintem CI != Unit teszt. Unit teszt soran biztosan nem akarnek RDBMS-t futtatni (dependency injection csodakra kepes) de a CI pipeline soran kesobb, funkcionalis vagy integracios tesztek soran minden bizonnyal igen. :vakarozos emoji:

( ivanov | 2019. 10. 26., szo – 19:33 )

Java alapú webservice-eket fejlesztek, abban az univerzumban:

- Unit teszt nem nyúl DB-hez, azon a szinten minden mock/fake.

- Functional tesztek (junit-tal futtatva, de itt már a service-t elindítva majd http-n meglőve) in-memory H2 DB-t használnak vagy direktben a használt framework hoz létre mindent vagy az ORM által generált sql fileok (source controlled) vannak a service indulásakor valamilyen DB migration eszközzel (flyway) futtatva. Az egyéb dependencyk mocked service-ként futnak (pl. az app mellett elindul egy wiremock is ugyan abban a JVM-ben és az válaszol a http hívásokra).

- Integration tesztek hasonló mint az Integration teszt csak itt minden valós dependency-t hív: igazi DB-t (csinál magának egyet), igazi service-eket, stb.

https://develotters.com

( Aadaam v | 2019. 10. 26., szo – 23:24 )

Szerkesztve: 2019. 10. 26., szo – 23:24

Lehet hogy bunkó kérdés, de az új HUP-ban hol van az “Eredmények megtekintése” gomb? Az amit azok az emberek nyomogattak akik nem akartak “csak az eredmény érdekel”-re nyomni, mint én, pláne amikor nincs ilyen opció...