Jump to content

shb

Members
  • Content Count

    30
  • Joined

  • Last visited

Everything posted by shb

  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
  16. I created a TestCase where I have overwritten the two class VIs listAllTestMethods.vi and countTestCases.vi. But the Tests listed in VI Tester are the same as before. What are this VIs for? Greetings, shb
  17. I would like to do this in my code too. Could you give some hints how this can be done? Maybe I will test this on some clean machines. (Somewhen in the feature.) Thank you very much for your answers. Greetings, shb
  18. I had to run it as an administrator user. When I started VIPM as a normal user, the window opened and closed some seconds later without showing an error message. (With a normal user I mean one that is not member of a special group. He must enter a different user name for an installation in windows vista.) The directory C:\ProgramData\JKI (on Vista) is created on installation. It is only readable for normal users. This is normal for LabVIEW Installers (changeable since VL 10) but not practically. Since I changed the permissions for this directory I can run VIPM without special privileges. Maybe I did something wrong. I am open to learn. Gretings, shb
  19. When ProgramData\JKI and its subdirectories are writable for everyone, the VIPM does not require administrator privileges, (except for some package installations probably). This is a big advantage when building packages and for installing simple packages (qd plug-ins, ...) Only switching to a special user after selecting to install packages looks like an ideal solution. No idea how this can be donw with LabVIEW. Greetings, shb
  20. What has helped is uninstalling VIPM, deleting all configuration (rename folder JKI in ProgramData) and reinstalling VIPM. Then I had to reinstall the packages for having the real configuration. Some packages required special tricks. Maybe uninstalling and reinstalling was unnecessary. Greetings, shb
  21. The issue is solved by VIPM 2010.0.1! It tells me that I am not allowed to create a package with no files. (I only wanted to include a function palette.) And when I include a file it works. Great. Thanks for the update. (And thanks for updating the news line. It is always nice to see action on feedback.) Greetings, shb
  22. Uninstall and reinstall did not help anything. Also not updating to the newest VIPM Version (2010.0.1, build 1581). Additional detail: The error message is shown after showing the text "Refreshing package database..." for some seconds in the status bar. I would really like to update my packages. I saw a new version of rcf is out but I can not get it. Greetings, shb
  23. Some more details. I can create the folder "D:\Data\LabVIEW\Packages\.PackageName" from LabVIEW (which runs as the same user as VIPM). When I try to create the package thereafter, the error message is the same as before. (An existing path would throw error 10.)
  24. I can create a new sibling folder from the file dialog from VIPM. So this means yes probably. (Of course windows forbids me to create a name starting with a dot out of a dialog.) And in this case I must correct: The reported directory is "ParentPathOfPackageSource\.PackageName". On my computer this is "D:\Data\LabVIEW\Packages\.PackageName". The drive D is my data partition (on the internal hard disc). Greetings, shb
  25. Today it works partially. The list was not empty after the first startup. I could even update a package. But after trying to check for packages, the list is cleared. I use VIPM 2010 (build 1568), Community Edition. It is upgraded from 3.0 which was upgraded from ... (By the way, the news line in top of this forum is quite old. 3.0) It has worked till about a month ago. There is no proxy in the company (none is configured in the browser). And when I see right the windows firewall only blocks incoming connections. Can it block outgoing too? What is the meaning of error 5009? Greetings, shb
×
×
  • Create New...

Important Information

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