You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Die Tests via test.sh/Docker lokal auszuführen geht zwar ganz okay - aber schöner wäre es, wenn man nicht lokal noch ein PostgreSQL bräuchte, auch um die Hürde für Contributors etwas herunterzusetzen.
Ev. kann man die Tests mit sqlite laufen lassen? Oder ev. macht's Sinn, ein subset der Tests die keine Datenbank nutzen laufen zu lassen in dem Fall?
The text was updated successfully, but these errors were encountered:
Das kann probleme geben, weil SQLite zB kein "alter column" kann und zudem viel weniger strikt ist bei der Validierung.
Zudem verwenden wir PG extensions, zB CITEXT.
Meiner Erfahrung nach sollte man immer mit dem DBMS testen, das man auch in Produktion verwendet. Mit Docker ist das aber relativ simplel, einfach einen temporären PG Container starten wenn man die Datenbank nicht lokal einrichten will.
Hmm, okay, sehe ich ein. Wie sieht denn euer Workflow so aus? Ich hab das bisher ähnlich gemacht wie auf Travis, also 1x docker-compose up (primär um das postgres zu kriegen), dann docker-compose run studentenportal deploy/dev/test.sh.
Das ist aber relativ nervig während der Entwicklung - die Tests brauchen so bei mir fünf mal so lang als ausserhalb von Docker (106s statt 21s, ev. auch wegen coverage?) und bei jedem Dependency-Upgrade muss ich den Docker-Container neu bauen...
Ich würd also folgendes vorschlagen:
docker-compose.yml so abändern, dass der Postgresql-Port auch auf dem Host exposed ist (auf Port 5432? Oder irgendwas anderes, falls man lokal schon ein Postgres laufen hat?)
deploy/dev/Dockerfile so abändern, dass die requirements nicht mehr beim Bauen vom Docker-Container installiert werden
deploy/dev/test.sh loswerden und stattdessen tox aufsetzen, was quasi Standard ist bei diversen Python-Projekten. Das warten auf Postgres, die Umgebungsvariablen, etc. lassen sich alles auch durch tox/postgres lösen.
Heisst in der Praxis:
Man kann den Docker-Container starten und dann via tox (wie in vielen anderen Python-Projekten auch) die Tests ausführen
Man kann (vermutlich) mittels ner Option an pytest auch easy nen anderen DB-Host/User/Passwort angeben, falls man ein lokales Postgres nutzen will
Zeitlich sollte es nicht viel Unterschied machen - tox/virtualenv behaltet ja die installierten Dependencies. Falls man die Tests weiterhin innerhalb von Docker ausführen will, dann geht's beim ersten Mal halt etwas länger.
Was meint ihr?
fabianhauser
changed the title
Tests ohne PostgreSQL / mit sqlite?
Tests ohne PostgreSQL / mit tox
Mar 18, 2020
Die Tests via
test.sh
/Docker lokal auszuführen geht zwar ganz okay - aber schöner wäre es, wenn man nicht lokal noch ein PostgreSQL bräuchte, auch um die Hürde für Contributors etwas herunterzusetzen.Ev. kann man die Tests mit sqlite laufen lassen? Oder ev. macht's Sinn, ein subset der Tests die keine Datenbank nutzen laufen zu lassen in dem Fall?
The text was updated successfully, but these errors were encountered: