feat: starting generic testing framework

[henryiii]

Starting a generic testing helper framework. For a third party to test their implementation, they can subclass the provided UnitTest fixture and implement the required methods producing histograms.

Thoughts so far:

• I could make this a Mixin, which would workaround a possible issue with discovery if you import it directly into your test file instead of keeping a dotted name. But then typing is trickier, so I haven't done that (yet).
• I could provide the suggested data contents. I think this might ideally follow serialization.
• This uses unittest not just because that avoids a dependency, but also because pytest won't rewrite an assert that's not in a test file. It can be run with pytest and still prints nicely.

Closes #133.

[Copilot]

Copilot reviewed 6 out of 7 changed files in this pull request and generated no comments.

Files not reviewed (1)

• docs/indexing.rst: Language not supported

[APN-Pucky]

I'd like to test the tests (APN-Pucky/babyyoda#60). May I request a new release?

[henryiii]

Have you at run your tests once with the current GitHub install? I'd like to know there aren't bugs in the tests and more exposure does help. :)

I'd like to get the serialization stuff done, but I guess that could be broken into two releases, one soon and one once that's in.

[APN-Pucky]

Have you at run your tests once with the current GitHub install? I'd like to know there aren't bugs in the tests and more exposure does help. :)

I was waiting for working/proven tests :), but I'll use the current git version then.

[henryiii]

If you can just make sure all the failures (if any) look like they are issues on your side, that would be great. If they are issues in the tests, I'd like to fix them before release - that's how we get working/proven tests. ;)

[APN-Pucky]

I think this data should be defined in the uhi.testing.indexing.Indexing, right? So that if the testing algorithm changes the data can also be changed only on the UHI side.

[henryiii]

It could, but we also test setting values. I was thinking this could wait till we have serialization support, then we could provide a serialized histogram someone could use if they didn't want to set it up manually.

[APN-Pucky]

Currently this directly compares the values (here int).

tests/uhi/generic.py::TestAccess::test_access_integer_1d - AssertionError: GROGU_HISTO1D_V3.Bin(d_sumw=0.0, d_sumw2=[44 chars]=1.0) != 0

In my case the bin also tracks the sumw2 as a members. Would it make sense to wrap the float(self.h1[1]) and my Histo1d bin would default to returning sumw for casting to float?

[APN-Pucky]

If you can just make sure all the failures (if any) look like they are issues on your side, that would be great. If they are issues in the tests, I'd like to fix them before release - that's how we get working/proven tests. ;)

I am using them now (https://github.com/APN-Pucky/babyyoda/pull/62/files#diff-0f092003db713d939e5d5a829a5bf816f16a4bec1708c796f2b5fc55c0dae36b though I disabled some for 2d case that I was too lazy to getting working for now).

[APN-Pucky]

I like the tests, because indeed some behavior I understood differently from the protocol explanation, compared to the tests. Most notably I thought arr[1:5:rebin(2)] would rebin from 1 to 5 but return the whole histogram range again. The tests instead showed that it should only return the rebinned subhistogram from 1 to 5. So the tests are really useful because they are unambiguous.