search

Doveps / mono

Code for Doveps projects
http://doveps.com
MIT License
0 stars 0 forks source link

03-09-2018: Continuation on Yesterday's work #127

Closed JosiahRegencia closed 6 years ago

JosiahRegencia commented 6 years ago

Still followed link: https://julien.danjou.info/blog/2014/db-integration-testing-strategies-python

Continued beyond its setup only. Went on to let the sh file set preconditions and then run the tests.

Unfortunately, I end up with this: /usr/lib/postgresql/9.4/bin/initdb: not found

I'm not really sure why, yet though.

I'm not changing our way to connect with the DB yet, though.

greenmoss commented 6 years ago

Can you give more info on the goal? The DB should already be running when the test starts. It shouldn't be necessary to test for db connection. At that point, you can "trust" that the db is ready.

For instance, check out "testing like travis" in https://github.com/Doveps/mono/wiki/Developing-with-Docker:

docker-compose build savant
docker-compose up -d

This starts up both savant and the db. Note in Travis we are also already waiting for the db before we start the test:

https://github.com/Doveps/mono/blob/master/.travis.yml#L6

The test is executed only after everything is confirmed started. The test command is executed inside the savant container, which means there are no problems with libraries:

docker exec mono_savant_1 python tests/test_basic.py

What this means for you testing locally is: start the db up like the example in the wiki. You will see it running db initialization commands. When it is done, the db is up. You can now run all of your tests.

For the goal of the tests, example https://github.com/Doveps/mono/issues/117, I dug around in the git commits. Note this commit in git history:

https://github.com/Doveps/mono/commit/c32b41c5a7708528e529ae25878b5f9d37d5e67e#diff-873d657db547c360d2e967dd1ebaa71aR40

There we used string "N/A". Then in the next commit

https://github.com/Doveps/mono/commit/3c5d423a40fbce39583cb694585a9fa2ce56da46#diff-873d657db547c360d2e967dd1ebaa71aR40

We changed "N/A" to None.

So the question is: "why did we have to us N/A"? If I remember correctly, the reason was that when you used "/flavor/create" with a special condition (I don't remember what it was, sorry), using None caused duplicate DB rows. So there's your test case. Insert using the APIs, and use that special condition which would have caused duplicate DB rows. Once you do that, your test then uses another API call to check the DB rows. It should assert it does not see a duplicate.

As far as I can tell, you can ignore the state of the DB for this test. If there is a need for a reset, we can look at that too. But get the basic test case in first.