Jump to content

shb

Members
  • Content count

    30
  • Joined

  • Last visited

Community Reputation

0 Neutral
  1. The package is in %ALLUSERSPROFILE%\JKI\VIPM\databases\LV 12.0\jki_labs_tool_vi_tester (when it is installed in LabVIEW 12.0) It is named jki_labs_tool_vi_tester-*.ogp It is (probably) also in the cache of the VI package manager: %ALLUSERSPROFILE%\JKI\VIPM\cache You can open the package by clicking it with the right mouse button, selecting "Open with ..." and then select the zip program. Or you can copy the package, rename it to ANYTHING.zip (ignoring the warning message) and open it by double clicking. The path of the file in the zip file is "File Group 0\resource\JKI\VI Tester\Templates\TestCase\TemplateTestCase.lvclass" Copy it to "LABVIEWDIR\resource\JKI\VI Tester\Templates\TestCase\" Greetings, shb
  2. The many dependent VIs are mainly a problem because LabVIEW loads all class VIs (and their SubVIs) when loading a class. And the dependencies in the LabVIEW project are filled with dependencies only for testing.
  3. I just messed up my installation again on an other computer. This time I fixed it by manually extracting the files from the vipm package. But now I used the opportunity to examine: The original owning class is "TemplateTestCase.lvclass". It also was last time, I have checked in the attached file. The problem seems to be that <resource> is a symbolic path in LV12. (Spotted in the class file attached to the original post.) When the template files are converted to LV12, they do not contain relative links relative to themselves, but links relative to <resource> When this files are copied or moved, their SubVIs still point to <resurces>/... When the files are not converted, <resource> does not exist, so the problem does not occure. I just tested this: I opened and saved the TestCaseTemplate.lvclass to LV12. A new created TestCaseClass contains the VIs in the original location <resource>/jki/.... I restored the TestCaseTemplate.lvclass (it's LV8.2 now). Creating a new TestCase works now. I do not know why the (class) files have been converted, whether this was done automatically or by accident. (Why did nobody else have this problem?) You probably must look for a new place for the Templates (containing TestCaseTemplate and TestSuiteTemplate), maybe somewhere outside the LabVIEW dir. Or you keep the files in the old version and somehow hide them that they do not get converted (even not by accident). (wrong file extensions, write protect them, put in a zip file, ...) My work around was to restore the template files from the vipm package (and hope). (I try to write protect them but this setting is copied to the new class, what is not what I want...) restore from vipm package: open the vimp package with a zip program or copy it and append the extension .zip, the double click [*] in the zip file, the files are located in "File Group 0\resource\JKI\VI Tester\Templates\" Greetings, shb
  4. When I create a test case a whole bunch of VIs appears in the dependencies because TestCase.lvclass needs them. They are too many in my opinion. Opening a TestCase takes too long. Some Ideas: Create an abstract Test Result This is how it is done in Python. This class depends on TestSuite. Load dynamically (and buffer?) the current result class in TestCase.lvclass:defaultTestResult.vi Or remove "TestResult.lvclass:Get Test Skip Message.vi" from the class. This VI seems to have the most dependencies. (Also on TestSuite) [*]remove the VIs which are not class VIs from the TestLoader.lvclass The VIs can be moved to a lvlib or be on their own. At least remove getTestsFromTestCaseObject.vi from the class, then TestCase.lvclass does not depend on TestSuite.lvclass [*]Maybe you will see more possibilities in the dependency diagram after this is done. I fail now. Greetings, shb
  5. Why are setUp.vi and tearDown.vi not Dynamic Dispatch VIs? This does not look like xUnit style for me. I would like to create an abstract test class (inheriting TestCase) which containts setUp and tearDown. This would be used by all Test Case Classes which inherit from this class. But this does now work. The VIs are not called when running a TestCase. And they can not be overwritten in a SubClass. I suggest to define setUp.vi and tearDown.vi in the TestCase class as Dynamic Dispatch VIs. This would have the following advantages: Easy creation in a Test Case Class by creating an overwrite VI. The VIs in each class are not necessary anymore. (Mine are often unchanged. Therefore I delete them.) setUp.vi and tearDown.vi can be defined in a parent class and they can be overwritten in a subclass Not sure how the transition to the dynamic dispatch VI should be done. When introducing them in TestCase.lvclass, all former test classes are broken. So maybe the new methods should have a different name (set_up.vi, set Up.vi, ...). The implementations in TestCase.lvclass could call the old VIs. The current workaround is to call VI of the parent class in the setUp.vi of the concrete test case. The called VI can be a dynamic dispatch VI. Greetings, shb
  6. One thought more. When a test fails error 42 is raised. The source reads like "TEST_FAILURE: ...". But this is not really the source but the reason. So I suggest to write the source as: "TestCaseName<err>TEST_FAILURE: ..." This would help when parsing error messages because error 42 and others would behave the same.
  7. In VI tester 1.1.2 a separate icon for broken test VIs was introduced. Thank you very much for this. I suggest two more Icons: * One icon for the currently running test * One separate icon for VIs raising an error different to a failure (error = 42, source = "TEST_FAILURE: ...") The icon for the running test would be helpful for tests which take a long time to run. When the run time is only some seconds showing this icon could be skipped.
  8. I see several possibilities: (parent class is myTests_A.lvclass) mark the parent class as abstract use the skip VI in ComonVI.vi in the parent class implement the first test case in the parent class (probably not a clean design) The decision of choosing the design could be left to the test case writer. When the parent class is not in the project (only in dependencies), it is not loaded with the project anyway. So it is easy to leave it out.
  9. Same behaviour in LV 12.0f1. With the workaround the toolbar is shown, but the buttons do not have an image. The tip strip works, so I find the desired button. And also me, I thank for the toolkit.
  10. I just stumbled over the application method "LabVIEW Class:All Methods of LVClass Method" which also lists the inherited VIs.
  11. The class SubCase.lvclass inherits from the test case myTests.lvclass (inheriting TestCase.lvclass). When loading SubCase.lvclass in VI Tester only the tests defined in this class are shown. I expected to also get the test VIs from the parent class. At least this is what I am used to from python unittest. I tried this because I have similar VIs I want to do 3 test on each. The connector pane of the VIs are similar, but some data types are different. So I wanted to handle this differences in a VI which is used in all 3 tests. In the subclasses I wanted only to overwrite this VI. My words are probably unclear, maybe this structur explains more. myTests_A.lvclass, inheriting TestCase.lvclass CommonVI.vi Test 1.vi, calling CommonVI.vi Test 2.vi, calling CommonVI.vi Test 3.vi, calling CommonVI.vi myTests_B.lvclass, inherinting myTests_A.lvclass CommonVI.vi
  12. Precondition: Project containing test case NotLoadable.lvclass NotLoadable.lvclass contains a VI TestUnloadable.vi TestUnloadable.vi can not be loaded. Examples: saved in a newer LabVIEW version, empty file Now lets start JKI VI Tester (from the Tools menu or the tool bar). The loading screen appears shortly and disappears without showing an error message. An error message should be shown and (maybe) the VI Tester could continue start up without loading this test case (or without loading the entire project). There is no problem when opening out of VI Tester (Menu "File", "Open project or Test Class..."). When opening the Project or NotLoadable.lvclass the following error message is shown: Error 1498 occurred at Get LV Class Default Value.vi Possible reason(s): LabVIEW: Library has errors. Fix the errors before attempting this operation. This behaviour is the same in LV8.6, LV11 and LV12 (always with the newest supported JKI VI Tester). By the way, why don't I see the VI Tester tool bar in LV12?
  13. When I create a new test case in LV12, it contains the VIs from TestCase.lvclass instead of the new created VIs. All the included VIs are affected (setUp.vi, tearDown.vi, and testExample.vit). (At least TestCase.lvclass is the parent of the new created class as it should be.) When a new VI is created from the template (selected in the context menu), it is shown in the correct class, but the VI title tells it is in TestCase.lvclass The VIs in the directory of the new class (setUp.vi, ...) claim to be part of TestCase.lvclass Creating a new test case with the same VI Tester Version works in LV11. See the attached class file for comparision. (I could not upload them with the correct extension.) I just had to uninstall and install the VIPM package of the VI tester because I have saved the TestCase.lvclass referencing the new created VIs. IfI had checked the list of changes more carefully, I would have detected the bug without messing up the installation. Details: LabVIEW: 12.01f 32bit JKI VI Tester: 1.1.2.164 test creation of TestCase_lvclass.txt test creation of TestCase_lvclass LV11.txt
  14. I tried to implement something like Parametrized Unit Testing. I currently use two work arounds: Create a test for every value. All this test VIs call a common SubVI executing the test. The test contains a loop which is run for every test value. The first failure breaks, the remaining are not run. I only overwrote countTestCases because only overwriting listAllTestMethods did not work
  15. I confirm this bug as closed in VI Tester 1.1.2.164
×

Important Information

By using this site, you agree to our Terms of Use.