It’s a mystery to me why we get two different outcomes for aperture correction in this specific test; it always alternates between just those two. I ran a quick test and found that there’s some randomness beyond the seeds we set in _makeTestData. I have to say, the image arrays themselves seem to be the same. If I save a test exposure and reuse it, the problem doesn't happen, i.e., I get the same base_PsfFlux_apCorr every time I run the unit test. Any idea why we don't get a unique value here?

My best guess would be that there's a seeded random generator being called N times in the first case and N+1 in the second, though I'm not sure what would cause that. This should be a follow-up ticket.

Aren't a lot of these settings defaults? Do you want these specific values tested rather than whatever the defaults are (which might change in the feature)? I can see the value in having one test that makes minimal changes to the defaults and another that tries to change as many as possible for maximal coverage.

Is this in nJy or the pre-calibrated flux which is ~0.02 nJy? If it's nJy then 3.0 seems quite large for atol.

Some of these should probably just be separate tests so you can run them in parallel, if desired. I suppose it's useful to run at least a pair serially to ensure there isn't some unintended state saved between runs, but not every time.

Does it persist them or just discard them after generating? If the former, should they be checked?

It would be nice to just loop over a list of expected output names, but I suppose they're only specified in the docs.

It might be helpful to define some of these expected values in setUp for consistency, and to make it easier to look up what they are.

If you don't care about the ordering you could make some_expected_columns a set and write missing = (some_expected_columns & set(table.colnames)) - some_expected_columns, though it doesn't really matter.

My best guess would be that there's a seeded random generator being called N times in the first case and N+1 in the second, though I'm not sure what would cause that. This should be a follow-up ticket.

This is a legacy function and shouldn't be used. Use e.g. numpy.random.default_rng(seed=565) instead.

I wonder if this is the cause of your semi-random result above? It shouldn't be, but two different results suggests a test order dependency.