Objects tests

[ChristianTremblay]

[ChristianTremblay]

All objects covered

[ChristianTremblay]

Tests are done for every objects. Some tests are failing because :

FAIL: test_object (test_ChannelObject.Test_ChannelObject) This object is not implemented yet

FAIL: test_object (test_LoadControlObject.Test_LoadControlObject) Need some help to define a shedLevel obejct, DateTime, ArrayOf(CharacterString)

FAIL: test_object (test_NetworkSecurityObject.Test_NetworkSecurityObject) Need help to define a ArrayOf(NetworkSecurityPolicy), AddressBinding (Sequence)

FAIL: test_object (test_NotificationForwarderObject.Test_NotificationForwarderObject) Need help to create a SequenceOf(EventNotificationSubscription)

[JoelBender]

I don't have any experience with channel objects. A DateTime object can be created like the other types in basetypes.py like this:

value = DateTime(date=Date(x), time=Time(y))

Where x and y are appropriate initializer values (in this case 4-tuples). A single NetworkSecurityPolicy is an object:

value = NetworkSecurityPolicy(portId=2, securityLevel='plainTrusted')

An Array object can be initialized with a Python array, like this:

value = ArrayOf(Integer)( [1, 2, 3, 4] )

but after that the array is accessed using BACnet array semantics where the first element of the array (index 0) is the length. The SequenceOf can also be initialized with a Python array and doesn't have the funky semantics.

[ChristianTremblay]

I found some doc on the ChannelObject... I'll send it.

[ChristianTremblay]

Thanks Joel for your help on defining ArrayOF, Sequence and others... Now every tests are passing. I will welcome your comments on the tests I made for objects.

[ChristianTremblay]

... I think I made bad assumptions on the function object_cannot_write_wrong_property_to_writableProperty

try / except is misplaced

I modified the function and now, I can't get a passing test as for some values, we can write to an object with a "almost the same type" object... actually no means to detect it automatically....

For now, I will pause and wait for comments.

[JoelBender]

The Channel Object is in Clause 12.53, so I'm all set with that. I'll check out the branch let you know what I find.

[JoelBender]

1. For each of the object types there is a list of self.listOfProperties which seems to be a duplicate of the list in in the object class, i.e., AnalogValueObject.properties, with the same information but is a different form. I'm guessing that the intent to to check that the definitions match when they come from two different sources?

self.listOfProperties = [(p.__class__, p.identifier, p.datatype) for p in AnalogValueObject.properties]

2. The places like this:

for each in self.listOfProperties:

would be a little easier to read if the tuple was unpacked:

for prop_class, prop_name, prop_datatype in self.listOfProperties:

3. the object_noWritingToReadableProperty function will pass the first time that obj.WriteProperty raises the ExecutionError, rather than testing all of them.

4. In object_can_write_to_writableProperty the last test self.assertEqual(nmbrOfSuccess,nmbrOfWritableProperties) will always pass because if any of the obj.WriteProperty calls raises an exception, the exception will be passed up to the caller and the function exits. The object_cannot_write_wrong_property_to_writableProperty function traps the exception close to the call.

5. In object_cannot_write_wrong_property_to_writableProperty you could raise an exception for the write succeeding rather than counting them:

try:
    obj.WriteProperty(actualProperty, each)
    raise RuntimeError("writing " + str(each) + " to " + actualProperty + " successful and should have failed")
except (TypeError, ValueError):
    pass

That way you'll get a better diagnostic message when the test fails.

6. The code seems to be missing tests for writable enumerated properties like mode in the Test_LifeSafetyPointObject because none of the values in the writeValues list will match.

7. This is a lot of work!

[ChristianTremblay]

1. The idea behind listOfProperties was to define the list needed inside the test. so if something is modified inside the object, test will notify it. I know it may seem like a repetition, but (maybe due to my lack of experience) I thought that when a new property is needed for an object, we must first define a failing test... then add the feature. This was a way to allow that.

2. Really good point ! Thanks for pointing this out.

3. Yeah I see... :-(

4. I'll work on that

5. Great idea ! I'll try this

6. I guess test pass when using a simple integer. Testing all enumerated value is a big challenge alone. Do you think we should add this there ? Or should we deal with them in their own tests ?

7. Yes. A great way to better understand what's behind the hood too. But I think that the helper make that "not a too hard to follow suite of tests" as everything's in it.