The test file tree seems to be quite messy. We have integration tests in the unit test directory and vice versa.
One of the main reasons this might have happened is because it can be hard to define what an integration test really is in MakeDrive's case.
It might be safe to say that we can consider an integration test to be a test that examines ONE piece of functionality that might involve multiple syncs or an entire sync process to occur (such that we test the end state of one side of the system i.e. either the client or the server).
A unit test on the other hand can be defined as a test that examines each step of ONE sync. This can be at the protocol level (testing a SyncMessage request/response pair) or rsync tests or route tests.
Usually a unit test would involve faking either the client or the server depending on the scenario but the test framework itself is in control of one of those components completely. This is not true for integration tests as we would control neither component and simply provide an input, let the system process it in multiple steps and then examine the final output (not testing intermediate outputs).
One suggested approach to this is to have the following tree structure:
The test file tree seems to be quite messy. We have integration tests in the unit test directory and vice versa. One of the main reasons this might have happened is because it can be hard to define what an integration test really is in MakeDrive's case.
It might be safe to say that we can consider an integration test to be a test that examines ONE piece of functionality that might involve multiple syncs or an entire sync process to occur (such that we test the end state of one side of the system i.e. either the client or the server). A unit test on the other hand can be defined as a test that examines each step of ONE sync. This can be at the protocol level (testing a SyncMessage request/response pair) or rsync tests or route tests.
Usually a unit test would involve faking either the client or the server depending on the scenario but the test framework itself is in control of one of those components completely. This is not true for integration tests as we would control neither component and simply provide an input, let the system process it in multiple steps and then examine the final output (not testing intermediate outputs).
One suggested approach to this is to have the following tree structure: