WIP: Lwlock unit tests #5953
WIP: Lwlock unit tests #5953
Conversation
|
@hlinnaka I created the branch in the wrong repository. So lets continue the conversation in this one:
Going to try to walk y'll on my train of thought. Last week I was reviewing a PR that resulted from an interview and realized that it did not have unit tests. This was around the distributedlog functionality. In order to do a Fake I would have to create some test around the LWLock to ensure that the it was And this train of thought brought me to the position where I am right now. The next steps that still need to be covered in this PR are: Create a fake for the LWLock functions that we need distributed log Hope this helped out understand where I am coming from |
|
Closed due to incorrect branch as a base |
joaopapereira
force-pushed
the
lwlock-unit-tests
branch
5 times, most recently
from
e369720
to
907fb5d
Compare
|
Have you considered running the tests in a real server environment? You can write test C code e.g. in |
I need a little bit more context to understand what you just said. |
If the user wants to run the same unit test multiple times using the macro `unit_test_with_prefix` it is now possible to differentiate between runs. This macro appends to the function name what is passed into the argument example: ``` unit_test_with_prefix(my_prefix_, some_test_name); ``` will be translated into `my_prefix_some_test_name` Commit 45f7ec09307ea40b1e2c3d4ac18d3af30825e0b3 on google/cmockery
Add a folder of Helper functions for unit tests in the same directory where the Mocks are stored Signed-off-by: Joao Pereira <jdealmeidapereira@pivotal.io>
In this commit the infrastructure to add fakes is added. Now we can create fake implementations of our objects in `src/test/unit/test_doubles/path/to/file/realfilename_fake.c` When we use them we need to add the following to the makefile: ``` shmem_fake.t: $(TEST_DOUBLE_DIR)/backend/storage/ipc/shmem_fake.o ``` This will include the fake instead of the real implementation of the specific object. As a proof of concept a shmem_fake was added with some tests that cover both the fake and the real implementation. --- Fakes are a different flavor of test doubles. Fakes and Mocks are Test Doubles are used for different purposes. The Fake object is usually used when we want the test double to mimics the behavior of object that we are replacing. This new object will respect the interface and will behave like the real object, but usually is implemented in a much more simple way and should not be used in a production environment. An example of a common use of a Fake is a InMemoryDatabase. In order to ensure that the Fakes are kept up to date we need to ensure that the tests we write for the real implementation are also running against the Fake, so that we are sure our Fake is still an acurate representation of the real object. The Mock object in the other hand functionally they are not smart. Their objective is to ensure that when you call the test double the interface is the same as the real object, but we control what is being returned at each call, and in the end they check that the object was called with the parameters that was expected. As per the explanation above the cost of writting a Fake is higher then writting a Mock in the short term. But in the long run if we need to use the same Mock object over and over again we will realize that eventually a Fake would have spared us some Test Code. In our example the Shared Memory object is a object that will be used in multiple instances of our tests and it make it easier to create a Fake that is able to replace the Real object and maintain the behavior.
Added test for: 1. NumLWLocks 2. LWLockShmemSize 3. LWLockAcquire 4. LWLockRelease 6. LWLockHeldByMe 7. LWLockHeldExclusiveByMe The first 2 tests are just to make sure we have enough coverage when we create the fake of lwlock. It will be helpful to ensure that the values returned from these functions is correct as well In this patch a new `expected_elog_with_message` function was added to the elog mocking helper to do the setup of the mock that ensure that elog is called with the correct format. This is where the Shared Memory fake starts to pay off. In this commit we add more functionality to our Fake to allow us to retrieve some "inner" information about the module itself. The functions `shmem_fake_get_total_memory_allocated` and `shmem_fake_retrieve_allocated_memory` allow us to look into the amount of memory allocated by lwlock and also to return a pointer to that shared memory. We are using this trick to allow us to manipulate the lwlock module information. This information is used to be able to test that a lock can only be aquired if no other process as it. There is more information about this in the comments of the functions that allow us to have this behavior.
joaopapereira
force-pushed
the
lwlock-unit-tests
branch
from
907fb5d
to
4125196
Compare
|
On 11/10/2018 23:29, João Pereira wrote:
Have you considered running the tests in a real server environment?
You can write test C code e.g. in |src/test/regress/regress_gp.c|,
and expose it as a SQL callable function.
I need a little bit more context to understand what you just said.
Are you suggesting the creation of function like
|test__LWLockAcquire_when_trying_to_aquire_101_locks_it_elogs_error|
that is run from a SQL file?
Yeah, something like that.
BTW, the 9.4 merge will break these tests, see commit ea9df81. And
9.5 will break them again (commit 3acc10c). That's probably just the
tip of the iceberg, there have been small changes to the internals of
LWLocks in almost every release, even thought the external API has
stayed mostly unchanged. This kind of tests on the implementation
details are very fragile. -1.
- Heikki
|
|
Me and Jimmy tried and interesting project where we tried to port the tests for the merge repository. It can be found Despite that it looks like there is not a great deal of interest in having this change committed. So I will close this PR in the next couple of days |
For now the PR is just a WIP because I still do not have the tests for the lwlock that I want. Feel free to take a look at this PR before it is ready as I would love to have some comments on the implementation of these Fakes.
What can you find in this PR:
Implementation of a Fake Test Double for the Shared Memory as well as some basic tests that will allow us to understand if the fake is behaving in the same way as the real implementation.
An example of sharing tests between both fake a real implementations.
Plumbing to replace the real implementation object with the fake ones
A PR that I sent to CMockery to add the prefix on the test name