tests: Refactor tests into unit and functional

[dkrako]

unit tests and functional tests should be clearly separated. unit tests test functionality of single specific parts of the software. functional tests test use cases that consist of several steps with defined outcomes.

Next step will be creating a directory named integration for integration tests. integration tests test the functionality in regard to 3rd party systems. these can be databases or servers, in our case we will start out with the usecase of downloading public datasets and doing basic preprocessing. This should then finally reproduce #517

[codecov]

Codecov Report

All modified lines are covered by tests ✅

Comparison is base (43c75ca) 100.00% compared to head (09d0caa) 100.00%.

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #589   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           52        52           
  Lines         2331      2331           
  Branches       581       581           
=========================================
  Hits          2331      2331           

Files	Coverage Δ
src/pymovements/gaze/io.py	100.00% <ø> (ø)

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[SiQube]

Hi before this get merged I wanted to write my two cents. Since we're refactoring we should move all the logic that we have in the tests into a testing repository and test it as well. It might as well be that we have bugs in all the logic we introduce within each of the tests scripts. This might be a different PR but better practice is to remove any logic from tests.

[dkrako]

Hi before this get merged I wanted to write my two cents. Since we're refactoring we should move all the logic that we have in the tests into a testing repository and test it as well. It might as well be that we have bugs in all the logic we introduce within each of the tests scripts. This might be a different PR but better practice is to remove any logic from tests.

Yes, this makes sense, and can then be put into tests/testing right? I think most of the logic is very straight forward, but maybe we will create some fixtures in the future that we want to reuse across tests or so? but that's something for the future

[SiQube]

I'd say it should be it's own directory, since we exclude tests from coverage, could be testing but in root.

[dkrako]

can you identify what particular logic of our tests you would like to have tests for and create an issue with this?

I see that for stuff like polars.testing.assert_frame_equal() this makes sense, but I can't really identify such logic in pymovements yet.