Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-22189

Improve test coverage for makeBrighterFatterKernel.py

    Details

    • Type: Story
    • Status: To Do
    • Resolution: Unresolved
    • Fix Version/s: None
    • Component/s: cp_pipe
    • Labels:
      None

      Description

      Coverage is poor at the moment, we need to make some tests.

        Attachments

          Activity

          Hide
          swinbank John Swinbank added a comment -

          Can we be more specific? “Improve X” is pretty open to interpretation. “Test that it does... A, B and C” would be nice.

          Show
          swinbank John Swinbank added a comment - Can we be more specific? “Improve X” is pretty open to interpretation. “Test that it does... A, B and C” would be nice.
          Hide
          mfisherlevine Merlin Fisher-Levine added a comment -

          At the moment there is no test coverage for this file whatsoever, so I think literally anything would be a start to be honest!

          Really this ticket was just made so that I could have something to put on the TODO's, but yes, it clearly should be more specific.

          The lack of detail here is actually a symptom of the problem: not having thought through exactly how to do this is also why the tests yet exist. I think it shouldn't be too hard to put in some tests for the gain measurement, application, and cross correlation measurement stages, but the kernel generation might be harder. I guess we could take whatever is generated once those other tests are written as gospel though, and therefore just assert it's not changing to make sure that we at least have an alert for when code changes that so it can't be accidental.

          Show
          mfisherlevine Merlin Fisher-Levine added a comment - At the moment there is no test coverage for this file whatsoever, so I think literally anything would be a start to be honest! Really this ticket was just made so that I could have something to put on the TODO's, but yes, it clearly should be more specific. The lack of detail here is actually a symptom of the problem: not having thought through exactly how to do this is also why the tests yet exist. I think it shouldn't be too hard to put in some tests for the gain measurement, application, and cross correlation measurement stages, but the kernel generation might be harder. I guess we could take whatever is generated once those other tests are written as gospel though, and therefore just assert it's not changing to make sure that we at least have an alert for when code changes that so it can't be accidental.

            People

            • Assignee:
              Unassigned
              Reporter:
              mfisherlevine Merlin Fisher-Levine
              Watchers:
              John Swinbank, Merlin Fisher-Levine
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:

                Summary Panel