Jump to content

Omar Mussa

  • Content Count

  • Joined

  • Last visited

  • Days Won


Omar Mussa last won the day on October 4 2012

Omar Mussa had the most liked content!

Community Reputation

5 Neutral


Profile Information

  • Gender

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Good point. Will verify this and add it to known issues. This is a known issue. Our known issues are here: http://forums.jki.net/topic/1003-vi-tester-known-issues/ Thanks for your feedback!
  2. Great ideas. Will keep these on our radar - your feedback is greatly appreciated!
  3. I've added this issue (Case 13680) to our known issues for VI Tester. Thanks for your help identifying the issue!
  4. This is an interesting idea and one we've thought about as well. One question I have - if you run the parent test case directly, do you skip execution of the tests in the parent class? How does the parent test case get treated? Ideas are welcome.
  5. This is correct - unit tests should not depend on execution order - that's one of the first principles of unit testing. What you should do is update the setUp.vi (and/or the tearDown.vi) in your TestCase class to setup the test (delete all unused files prior to running a test, create files needed for testing, etc). In the tearDown.vi you can delete all files that are no longer needed, etc. I hope that helps - let us know if you still have questions.
  6. At this point, I see these VIs as part of the framework that you don't need to overwrite. countTestCases should not be overwritten. I'm not even sure why its over-writable - will check into that. listAllTestMethods I think can be used to replace the framework's dynamic discovery of test methods. I think this VI is intended overwrite-able but I will have to verify that. Out of curiosity, why are you trying to overwrite these methods?
  7. The EasyXML VIs are currently not re-entrant. I will look into why that is the case as I can see use cases for using the EasyXML functions in parallel.
  8. You can't test privately scoped VIs directly as they can never be called outside of their library. You basically have two choices: 1: Test a caller of the VI (the caller can be Public or Community scoped). The caller can be created just as a wrapper for the purpose of testing the code. 2: Change the VI under test's scope from Private to Community and add the TestCase where you want to create tests as a 'Friend' of the library. Hope that helps! Omar
  9. Hi Joe, I'm glad that you're having success getting started with VI Tester! This is a simple question with a complex answer. Low hanging fruit answer: You can improve the testability of your Action Engines by having the Action Engines call a specific VI in each state (Initialize state can call an Initialize VI). This makes it easier to test the Action Engines for various conditions. Additionally, you can have the core logic encapsulated in such a way that the inputs (while they come from data stored in other Action Engines) are testable under test defined conditions.
  10. Some unanticipated changes in 2011 broke the project integration with the toolbar. You can still launch VI Tester from 'Tools-->VI Tester-->Test VIs ...'.
  11. That seems strange. The help should open in a web browser, can you ensure that you have a default web browser selected (if its a new computer and you've never opened a browser, then it could create this issue)? Post back whether this works, if it doesn't help, I'll see if I can reproduce the issue. I tried opening the help on an XP machine running LV2011 and it worked fine just now. I can try it on a Windows 7 machine if you're still having issues.
  12. Currently, the 'Easy Write XML File' function will only write to a new file, so you need to delete the target file prior to calling 'Easy Write XML File'. If you are modifying an existing file, you need to read the target file (using 'Easy Read XML File'), edit the file, delete the target file and then call 'Easy Write XML File'. We're looking into ways to make this better in the future.
  13. Yes, you are correct! TestSuites can contain subgroups of TestCases (and also TestSuites). The way you declare which tests you want to add to a TestSuite is by updating the 'New.vi' method of the TestSuite. In the example image above, MyTestCase1 and MyTestCase2 are the tests that I've added to the TestSuite. These will now show up beneath the TestSuite on the Test Hierarchy tree in the GUI. Sorry for the lack of documentation! We're still working on the documentation aspects of the product. Let us know if there are other areas where you could use additional documentation/gui
  14. Thanks for reporting the bug! I've added it to the Known Issues.
  15. Good to know. We'll definitely look into adding warnings about unsaved changes to the .lvclasses, as this is a usability issue. What we are trying to do is avoid loading the .lvclass into memory unnecessarily - it adds a lot of time depending on your class hierarchy, size, etc. But ideally, this should be transparent to VI Tester users. Thanks for your help. Please post more feedback as you use the product.
  • Create New...

Important Information

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