Debugging Your Interface and Protocol Projects

The Semiconductor Device Control Add-On Professional edition distributes the interface and protocol project templates with a unit test project that you can use to test the logic of the custom interface or protocol. Visual Studio creates the unit test project when creating a new custom interface or protocol project. The name of the unit test project is the same as the project appended with the word Test and located in the same location as the project.

Debugging a Custom Interface Project

Use the unit test project to debug a custom interface project.

Each API in the interface project has a respective test method in the unit test project. The unit test project includes the following test methods:

Table 23. Interface Project Test Methods
Method Name Description
TestInterfaceInstantiate()
  • Tests if the interface can be instantiated properly using the interface constructor. For testing purposes, the interface name is Example.
  • Fails when the instantiation of an interface raises an exception.
  • Requires that interface instantiation occurs without any issues, because instantiation of an interface is a critical step in testing the interface.
TestInterfaceStartAndStop()
  • Tests the Run() and Stop() APIs of the interface.
  • Instantiates the interface and executes the Run() and Stop() methods, respectively.
  • Any error in instantiation of the interface or in the Run() or Stop() methods fails this test method.
TestGetInterfaceSettings()
  • Tests the GetInterfaceSettings() API by verifying if the number of setting values received is valid.
  • Instantiates the interface and calls the GetInterfaceSettings() API to obtain all settings of the interface. This test method then compares the settingCount variable with the number of settings obtained and determines the status of the test.
  • You must update the settingCount variable with expected number of settings before starting the test. The settingCount variable is set to zero by default.
TestGetInterfaceDynamicSettings()
  • Tests the GetInterfaceDynamicSettings() API by verifying if the number of setting values received is valid.
  • Instantiates the interface and calls the GetInterfaceDynamicSettings() API to obtain all settings of the interface. This test method then compares the dynamicSettingCount variable with the number of settings obtained and determines the status of the test.
  • You must update the dynamicSettingCount variable with expected number of settings before starting the test. The dynamicSettingCount variable is set to zero by default.
TestInterfaceUpdateAndValidateSettings()
  • Tests the UpdateAndValidateSettings() API by verifying the update and validation of the settings given in the updatedSetting variable.
  • You must provide the test setting name and value in the updatedSetting variable. Refer to code comments for more information about specifying the updatedSetting variable.
  • Checks if the validation passed by checking if the validated setting result is empty. If the validated result returns an error, the test fails.
TestInterfaceUpdateAndValidateDynamicSettings()
  • Tests the UpdateAndValidateDynamicSettings() API by verifying the update and validation of the settings given in the updatedSetting variable.
  • You must provide the test setting name and value in the updatedDynamicSetting variable, similar to the TestInterfaceUpdateAndValidateSettings() test method.
  • Checks if the validation passed by checking if the validated setting result is empty. If the validated result returns an error, the test fails.

Debugging a Custom Protocol Project

Use the SampleTest unit test project to get started debugging a custom protocol project or PXIe-657x protocol project.

Complete the following steps to debug a custom protocol project or PXIe-657x protocol project.
  1. Add a reference to the parent interface into the unit test project.
  2. Replace the InterfaceBase class name with the name of the interface constructor throughout the unit test project wherever the interface is instantiated. Refer to code comments for more information about replacing the InterfaceBase class name.

Custom Protocol Test Methods

Each API in the protocol project has a respective test method in the unit test project. The unit test project includes the following test methods:

Table 24. Protocol Project Test Methods
Method Name Description
TestProtocolInstantiate()
  • Tests if the protocol can be instantiated properly using the interface constructor. For testing purposes, the interface name is Example.
  • Instantiates the parent interface and then instantiates the protocol.
  • Fails when the instantiation of a protocol raises an exception.
  • Requires that protocol instantiation occurs without any issues, because instantiation of a protocol is a critical step in testing the protocol.
TestProtocolStartAndStop()
  • Tests the Run() and Stop() APIs of the protocol.
  • Instantiates the protocol and executes Interface Run(), Protocol Run(), Protocol Stop() and Interface Stop() APIs methods, respectively.
  • Any error in instantiation of the protocol or in the Run() or Stop() methods will fail the test method.
TestGetProtocolSettings()
  • Tests the GetProtocolSettings() API by verifying if the number of setting values received is valid.
  • Instantiates the protocol and calls the GetProtocolSettings() API to obtain all settings of the protocol. The test method then compares the settingCount variable with the number of settings obtained and determines the status of the test.
  • You must update the settingCount variable with expected number of settings before starting the test. The settingCount variable is set to zero by default.
TestGetProtocolDynamicSettings()
  • Tests the GetProtocolDynamicSettings() API by verifying if the number of setting values received is valid.
  • Instantiates the protocol and calls the GetProtocolDynamicSettings() API to obtain all settings of the protocol. The test method then compares the dynamicSettingCount variable with the number of settings obtained and determines the status of the test.
  • You must update the dynamicSettingCount variable with expected number of settings before starting the test. The dynamicSettingCount variable is set to zero by default.
TestProtocolUpdateAndValidateSettings()
  • Tests the UpdateAndValidateSettings() API by verifying the update and validation of the settings given in the updatedSetting variable.
  • You must provide the test setting name and value in the updatedSetting variable. Refer to code comments for more information about specifying the updatedSetting variable.
  • The test method checks if the validation is passed by checking if the validated setting result is empty. If the validated result returns an error, the test fails.
TestProtocolUpdateAndValidateDynamicSettings()
  • Tests the UpdateAndValidateDynamicSettings() API by verifying the update and validation of the settings given in the updatedSetting variable.
  • You must provide the test setting name and value in the updatedDynamicSetting variable, similar to the TestProtocolUpdateAndValidateSettings() test method.
  • Checks if the validation passed by checking if the validated setting result is empty. If the validated result returns an error, the test fails.
TestProtocolRegisterWrite()
  • Tests the WriteRegister() API by writing the given test values and checking for errors.
  • You can specify the test register address and register data in the variables regAddress and regValue, respectively. By default, the address of 10 is used with the value of 100.
TestProtocolRegisterRead()
  • Tests the ReadRegister() API by writing a value and seeing if the read data matches the returned value.
  • You can specify the test register address and register data to use for write and read operations in the variables regAddress and regValue, respectively. By default, the address of 10 is used with the value of 100.
  • By default, the size of the data to be read is a byte length. You can adjust the default logic in the ReadRegister() API based on your use case.
  • Checks if the returned read data is valid and matches the data written.