Migrate Test_oM from Test_Toolkit into core BHoM

[al-fisher]

Following discussions and planned further development and deployment of our UnitTest strategy - @IsakNaslundBh @FraserGreenroyd @LMarkowski capturing discussion and further thoughts below.

1. Firstly "Create UnitTest from Method" component. required in UIs (naturally firstly focused only on Grasshopper)

2. The above raises the issue of dependencies between UI and Test_Toolkit.
   Test_Toolkit necessarily needing to be isolated and have visibility across all other repos (say for testing of core Adapter and perhaps future testing of UI say etc. etc.)

3. However in line with general plan of having all object models gradually converging and coordinated in core oM -
   suggesting moving the UnitTest object / Test_oM into the core BHoM repo.
   Keeping all the Test Engines naturally in Test_Toolkit

4. This will add extra importance on the planned isolation of Test_Toolkit through Nugets rather than direct reference.
   This is as planned but (especially while development is still occurring of testing itself), we will need to manage changes to Testing oM, planning well, such that updates to nugets are not too frequent. Ultimately settling to Betas and once a milestone.
   Thoughts on above will be good as to whether this is an issue/pain in either short and/or long term.

5. The other issue to be addressed is what namespace to place the current UnitTest object in.
   Looking ahead I can see a general interface and/or very similar concepts to the UnitTest being used for verification of our workflows/engineering/designs themselves. @alelom as per discussions. Will be keen to merge/share approaches.

So in summary might suggest moving the current UnitTest into BH.oM.Programming.Test namespace.

This leaves space for other Testing activities/concepts in other namespaces - which can be gradually coordinated/influenced by this - but does not slow down the current critical focus.

It also means - if we prefer - we could only migrate UnitTest and TestData objects across - leaving other objects in Test_oM and Test_Toolkit for the time being. @FraserGreenroyd - this might help with mitigating some of the annoyance of Toolkit depending on live BHoM. At least until this settles somewhat.

@IsakNaslundBh @FraserGreenroyd @alelom @adecler thoughts on the above? 😄

[IsakNaslundBh]

To put it in public here, as have only agreed on it in calls before, agree on migrating the test objects needed from Test_Toolkit to the core BHoM repo.

Not sure if programming is the right place for it though? (even though I understand why it is being suggested).

As an alternative, could we:

• Add Test_oM to the core BHoM repo
• Add a new ComplianceTest_oM in Test_Toolkit to take care of any of the compliance objects in there that does not make sense to migrate to base.
• Migrate the rest to Test_oM in the base

Personally think I prefer that over adding test obejcts to Programing sub namespace, but if this is disagreen upon, can live with that to move this forward.

[FraserGreenroyd]

I'm against adding Test_oM to the core BHoM Repo because, as discussed on the call, we (along with discussion from @adecler so tagging to loop him in) explicitly removed Test_oM from the BHoM repo and moved it to Test_Toolkit. So I feel we need to address the reasons for moving it out as well as the arguments for moving it back in, otherwise we could find ourselves in a similar situation in 12 months time wanting to move it back out again and Test_oM becomes the left leg of the hokey cokey xD

Otherwise I do not disagree with the idea.

[IsakNaslundBh]

So I feel we need to address the reasons for moving it out as well as the arguments for moving it back in

From memory, I think the reason we moved it out was to keep the oM in the toolkit that is doing most of the work for it. We thought it was contained, and could live its own life, with nothing outside of test toolkit needing any parts of it. And now it has simply turned out that we were wrong. But happy for anyone with more knowledge to change my mind on this, if this is not the case.

[al-fisher]

@FraserGreenroyd - on your point of moving the oM around. I beleive the decision previously was more to do with a move away from the BHoM_Test approach embedded within Toolkits - and where we had individual Test projects and the separate BHoM_Test repo. We centralised testing to the current Test_Toolkit.
Happy that as we are wanting to broaden the access to the Test objects we migrate to core oM. Is more a meandering maypole dance than hockey cokey I would say 😄

[al-fisher]

@IsakNaslundBh on your point - yes can agree too. The fact is you could apply a UnitTest outside of a Programming context too, is perhaps your point.

Why I was concerned is we are also looking at similar concepts elsewhere - wanting to encode "compliance checks" on relationships between pairs of objects - which may or may not partly overlap with the UnitTest concept in it's current form.

Current ideas are around defining a "Specification" Check which could contain a methodbase (similar to a unit test) but rather than provide input/output pairs - contains ranges of allowable outputs - given any input.

Don't want to over complicate or try to converge too soon - so was wonder if keeping in separate namespaces - but perhaps a Test_oM is indeed a big enough playground anyway.

Could be happy with simply keeping Test as a namespace and your proposal

Add Test_oM to the core BHoM repo
Add a new ComplianceTest_oM in Test_Toolkit to take care of any of the compliance objects in there that does not make sense to migrate to base.
Migrate the rest to Test_oM in the base

[adecler]

I agree with @IsakNaslundBh . I think Programming_oM and Test_oM are two different entities and are better kept separated for the same reasons that Reflection_oM is a separate thing.

Otherwise, I am happy to migrate Test_oM back into to core repo if there is enough use of it outside the Test_Toolkit.

[FraserGreenroyd]

Ok, to confirm then, I will raise issues that undertake the following actions:

• Move @IsakNaslundBh test oM code out of Test_Toolkit into BHoM
• Generate a new Test_oM project within BHoM for those objects
• Remove the objects from Test_Toolkit
• Rename the oM in Test_Toolkit to CodeCompliance_oM

I will action these today as part of this sprint to get them out of the way and allow @IsakNaslundBh space to continue his bits 😄