You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Trying to unravel my thoughts on a few things here. Eventually I
would like to be able to introspect a script and be able to do things
like:
Report the test list/test hierarchy. Possibly things like the test
description and if setup/teardown/enter/exit are defined. For tests
that are parameterised, print the parameter values.
Following from that, a script with variants, it would be good to
show the difference/similarities between test lists.
Report/audit the instruments needed for a given test script.
For the mux/switching definition, report the VirtualMux signal
map and the list of pins defined by each AddressHandler.
For many objects, there is no trade off to make. The script
just defines test classes etc. Builds a test list from test
class instances. Because instantiating a test class has no
side effects, this works fine. (At least, it should have no
side effects!)
The tricky bit comes when software meets the "real world".
JigDriver and other instrument drivers need to open hardware
connections. That is, that have side effects. I'll use the
example of an AddressHandler, but this can be extended to JigDriver
and other instruments.
There are two options:
Define a (sub)class that can be introspected, create an
instance to open hardware resources.
The class can accept parameters to init to customise it
(pin list, hardware address etc), but then it needs an
open method, so we can instantiate without invoking side
effects.
A test script defines a sub-class of AddressHandler with the
required customisation needed for that script. Then JigDriver
can be passed the class. Introspect the class as needed without
instantiating.
When ready to create an instance, just call the class and leave
it up to init to create/open the required hardware resource,
but that doesn't happen until it is needed. This flows up through
the whole structure:
driver manager
jig driver
address handler
And we want everything to be typed, so we can check and get
decent IDE support...
The text was updated successfully, but these errors were encountered:
Trying to unravel my thoughts on a few things here. Eventually I
would like to be able to introspect a script and be able to do things
like:
description and if setup/teardown/enter/exit are defined. For tests
that are parameterised, print the parameter values.
show the difference/similarities between test lists.
map and the list of pins defined by each AddressHandler.
For many objects, there is no trade off to make. The script
just defines test classes etc. Builds a test list from test
class instances. Because instantiating a test class has no
side effects, this works fine. (At least, it should have no
side effects!)
The tricky bit comes when software meets the "real world".
JigDriver and other instrument drivers need to open hardware
connections. That is, that have side effects. I'll use the
example of an AddressHandler, but this can be extended to JigDriver
and other instruments.
There are two options:
instance to open hardware resources.
(pin list, hardware address etc), but then it needs an
open method, so we can instantiate without invoking side
effects.
A test script defines a sub-class of AddressHandler with the
required customisation needed for that script. Then JigDriver
can be passed the class. Introspect the class as needed without
instantiating.
When ready to create an instance, just call the class and leave
it up to init to create/open the required hardware resource,
but that doesn't happen until it is needed. This flows up through
the whole structure:
driver manager
jig driver
address handler
And we want everything to be typed, so we can check and get
decent IDE support...
The text was updated successfully, but these errors were encountered: