Write tests for new STIX 2.1 objects

[emmanvg]

As we move forward with the new STIX 2.1 objects. He have to make sure they work as intended and also keep our code coverage scores in par.

[emmanvg]

Would it make sense to use some of the same tests to check STIX 2.1 aside from only adding tests for the new objects?

Some areas have potential to be extended using @parametrize and use it to create instances from X version.

[emmanvg]

It can help to keep coverage high. Recent local testing showed coverage lowering to 94%...

[gtback]

Rather than how the current tests will test only the newest version of the objects, we should have separate tests for both the v20 and v21 objects.

[emmanvg]

I have been working on the STIX2.1 branch update. A problem that I see arising is the datastores. Essentially, anywhere we use parse() or Bundle() we need to make a decision on what version to call/use or re-visit the current approach.

Among the approaches, we can check the spec_version property for SDO/SROs since it is a required property for 2.1 and if not present it is implicitly 2.0. It may be a bit more challenging, but using a combination of that and checking the Bundle we might be able to figure out which version to use in the parse(obj, version='...') call when a Bundle is received in a datastore object.

Now, another issue is that internally we make use of the Bundle class in all three datastores. My initial though says that we should add another argument to specify in which version you want to serialize, but it may be the case we are working with SDOs/SROs of mixed spec versions. Thus, we should spend some time thinking on the best way to move forward with this.

This is just for awareness as I go through the code update... @gtback, @clenk, @mbastian1135

[gtback]

And here I was, thinking that supporting 2.0 and 2.1 at the same time wouldn't be that hard. ☹️

Thanks, @emmanvg . We'll need to think through this some more.