Unit Testing

[AdvancedImagingUTSW]

Our unit testing is lagging. But, simply creating an issue requesting unit testing will not work either. So, some strategy is needed.

I have created a project under the Dean Lab GitHub organization. Here, we can be more granular than we can be in the 'issues' section. So, here, we will take subsets of the repository that does not have proper unit testing, and assign it to some of the key individuals who were responsible for developing it. We have target dates to hold ourselves responsible, and we can then spread the unit testing out over a period of months without becoming apoplectic.

Few takeaways:

• To maintain organization, we our test directory will mirror the organization of the src directory.
• File names will also mirror the portions of code that we are testing, prepended with test_ : Thus, the file image_contrast.py in src will become test_image_contrast.py in test.
• Within the test file, each function to be tested will also be prepended with test_, this is how the testing suite we are using works. See here for more info.

We have all worked really hard on the software, and it is starting to really become powerful. Now we have to also work to make sure that it grows gracefully. The more people working on the project, the better the tests have to be!

[AdvancedImagingUTSW]

I also welcome any other suggestions on how best to build out quality, informative unit tests.

[zacsimile]

Totally agree. We need this software to be robust, and unit tests are our first line of defense against errors. Maybe have a look at https://stackoverflow.com/questions/61400/what-makes-a-good-unit-test and https://medium.com/chris-nielsen/so-whats-a-good-unit-test-look-like-71f750333ac0 for general philosophy on writing a good unit test.

[AdvancedImagingUTSW]

Another rain delay preventing us from taking off. Was supposed to be in the jungle last night.

I just wanted to touch base on this again. I am waiting for @conorhughmcfadden and @Elepicos to accept an invitation to the Dean Lab organization, so that they can be tagged in the more granular list of unit tests to knock out.

I've already tagged @annie-xd-wang, @zacsimile, @codeCollision4, and @BingyingChen on some tasks. Bingying, the unit tests I'm asking you to fill out are largely done. But it would be good for you to make sure that all of the functions are tested, and that they are actually intelligently done.

Our goal is to knock this round of unit tests out by next Friday, 10/28.

[zacsimile]

@annie-xd-wang pointed out the rather useful @pytest.fixture decorator: https://docs.pytest.org/en/6.2.x/fixture.html. I recommend using this where possible. The description of a test on this page is quite helpful, conceptually.

[zacsimile]

We could consider going big with something like

@pytest.fixture(autouse=True, scope='package')
def dummy_model():
    from aslm.model.dummy import DummyModel
    
    model = DummyModel()

    return model

[annie-xd-wang]

Yes, I agree with the idea that making DummyModel a package-level pytest.fixture. We should add the definition of the dummy_model or any other reusable fixtures to a conftest.py file and they should be placed under different folders according to their usage scopes.

[codeCollision4]

Would it be useful to add the init tests for all devices as fixtures? That way we don't have to keep importing things over and over in each test?

As an example the StageBase init test, could call upon the Dummy Model fixture:

from aslm.model.devices.stages.stage_base import StageBase
from aslm.model.dummy import DummyModel

model = DummyModel()
microscope_name = model.configuration['experiment']['MicroscopeState']['microscope_name']
stage_base = StageBase(microscope_name, None, model.configuration)
stage_config = model.configuration['configuration']['microscopes'][microscope_name]['stage']

Then all other tests in the Stage Base (or other device) can use fixtures, then if we ever have to change the init section it will reflect thru all tests

[annie-xd-wang]

You bring up a good point that how we organize those fixtures and test cases. Since we are doing bottom-up tests, we could add those reusable fixtures as we write more test cases and figure out a more clear structure for doing the test. This is still an open discussion.
For now, we could group test cases into a class for a device-level test. You could view https://github.com/TheDeanLab/ASLM/blob/ea27022a9c72b233a53d8217f2f51bcde942192d/test/model/devices/camera/test_camera_synthetic.py as an example.

[codeCollision4]

Sounds like a plan. I'll follow the class-based grouping for now. Thank you