Jump to content

Omar Mussa

Members
  • Content count

    86
  • Joined

  • Last visited

  • Days Won

    3

Omar Mussa last won the day on October 4 2012

Omar Mussa had the most liked content!

Community Reputation

5 Neutral

1 Follower

Profile Information

  • Gender
    Male

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. Omar Mussa

    No VI Tester Project Window toolbar in LabVIEW 2011

    I've added this issue (Case 13680) to our known issues for VI Tester. Thanks for your help identifying the issue!
  4. Omar Mussa

    Suggestion: test classes inherit test methods

    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. Omar Mussa

    Idea for VITester

    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. Omar Mussa

    Overwriting some class VIs has no effect

    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. Omar Mussa

    Are easyXML fucntions reentrant?

    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. Omar Mussa

    Testings VIs inside LabVIEW Project Libraries

    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. Omar Mussa

    How to create *simple* tests

    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. This is basically what Test Driven Development can help you achieve in terms of designing more testable systems. Another way to solve the problem is to create mock objects that are used to simulate the Action Engine's dependencies (which are additional Action Engines). Ben Hysell wrote a good blog article about how to do this here. His example uses an object oriented architecture - in principle you can do this with an Action Engine hierarchy that is not OOP based, but OOP definitely makes it easier to swap in mock objects for the purpose of testing. In order to actually run using mock objects, I typically use a TestSuite to instantiate mock dependency objects that are used by the TestCase (which is testing a specific mock object). You are correct that creating more tests can add to development overhead. We're actively working on ways to reduce this overhead, but some overhead will always exist. So it is worth it to evaluate where you want to spend the effort to create tests (i.e. Where do I get the most bang for my buck?). Cheers, Omar
  10. Omar Mussa

    No VI Tester Project Window toolbar in LabVIEW 2011

    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. Omar Mussa

    Detailed Help seems to be missing ...

    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. Omar Mussa

    Edit XML

    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. Omar Mussa

    Adding a test case to a test suite

    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/guidance. Also, let me know if you're still confused about how to add tests.
  14. Thanks for reporting the bug! I've added it to the Known Issues.
  15. Omar Mussa

    Can't run test case :-(

    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.
×

Important Information

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