If one was to test the number of restaurants by postal code he would require some knowledge on the actual location of the postal codes. Possibly a fraction of them, but definitely real data. Most probably, there will be a table that contains the postal codes. Suppose an application that has to count the number of restaurants inside postal codes. This specially important when data comes from an ETL. Note that, we can actually opt-in for constraints just by doing:ĬREATE TEMPORARY TABLE table_to_test LIKE table_to_test WITH CONSTRAINTS Ģ. Having to set a proper birth date would be coupling independent parts. However, in a particular test we might be testing logic related to addresses. It might be the case that we have constraints on the birth date so that age is not null or not negative. Consider the case that we are testing a table of users. When testing it might be beneficial not to have the same constraints as the original table. By default, Postgres sets the temporary schema earlier in the search path, so any query will hit first our temporary table. The search path is analogous to $PATH in Unix, it determines in what order the schemas have to be searched for the name of a table. Will return data from that fake table that we created. How it worksĪfter we have built the temporary table, any query like: SELECT * FROM table_to_test For that we can do:ĬREATE TEMPORARY TABLE table_to_test LIKE table_to_test ģ.
We create a temporary table with the same name as the table that we want to test.If we are pooling outside the application, for example with PgBouncer we need to ensure that PgBouncer has exactly one connection and that connection does not close. If we are doing pooling at the application layer that will be easy, we just need to stub our pool to always return the same client. Make sure that there is exactly one connection from the application to the DB.The strategy to mock tables consists of three steps: That is exactly what we explain in this article. That way we can modify the data as we wish with the knowledge of what the output should be. What we need to achieve is that Postgres reads the data that we want from the tables that we query. Another option would be to seek an in-memory version of Postgres, but that isn’t good either, there is no guarantee that results will be the same, and of course some functionality might be lacking. However, it is far from optimal, queries can get complicated and we have hidden logic in them, which has to be tested. A first instinct would be to mock the answer from Postgres. Let’s focus on a Postgres application: a server written in any language (NodeJS, Python, Go…) which connects to a Postgres database.
an E2E test, but in general it is better to test the different parts in isolation and for that, one has to mock the interfaces. In general, a system is built out of a lot of components: some frontend that the users interact with, several backends, several stores… One could test such a system as a whole, i.e.
0 kommentar(er)
