I personally actually prefer your testv0 method. The way I understood it is a full stack testing that requires putting data into the DB and query them back.<p>What's wrong with that? It might be just a bit slower but for me that kind test is a lot of comprehensive. I have in the past has to slightly change the DB schema. Because of full stack test coverage were in place, full functional tests make all the bugs caused by schema change visible immediately.<p>For me, schema changes in DB cause some other operations to the DB failure is much difficult to detected and fixed if the issue is not visible to the developer immediately.<p>It might be slower (~a few minutes for ~300 full funtional test scripts run directly from the web-browser side) instead of seconds in your case, but I think the time is well spend for how quickly complex issues can be discovered and fixed.<p>BTW, I keep track of all DB operations (sql query) time as part of the json response. If they are > 1 milliseconds (SSD HD), I will flags them as potential issue in bugs DB for future investigation for SQL optimization.<p>It should be easy to add the SQL query response time to a performance DB to track and change over time/sw version.
I didn't see any schema tests for the db. Testing the DAO is its own concern, and I can't consider that as unit test coverage for the schema portion of the project. I would normally be looking to something like PgTAP here.<p>(For the "oh really?" crowd, here's a brief rundown on what I often test: object permissions/owners, function correctness, non-trivial constraints, triggers (usually existence testing, sometimes functional verification), application-global data. And yes, it is great to have all that nailed down before diving into writing a DAO)
They switched from angular to essentially a static site for SEO reasons. I wonder if they're batch generating the static pages or making them dynamically on request.