Jump to content

Omar Mussa

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Omar Mussa

  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. 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. 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/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. 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.
  16. That's great! I'm glad you're making progress. So, the reason for this is that we changed the way VI Tester works - it used to load the test classes into memory to find the test methods. This was very slow for large projects, so we changed the code to discover test methods by inspecting the class on disk. We need a warning flag if you try to load a TestCase with unsaved changes as it may not show up in your test list (Added to 'Known issues': Case 10770). Note - once discovered, you can edit the code within the tests while the VI Tester UI is open without any issues - this is just a load time effect. Can you attach your custom TestCase.lvclass file to this thread? I want to ensure that we don't have a localization issue that would affect you (or other users). What trouble are you having? Make sure the TestCase is saved after you add the testExample.vi. Thanks for your patience! I'm pretty confident that you'll be able to run unit tests without any issues once you get past these initial hurdles.
  17. I think I know what's wrong - its actually a documentation bug in our manual. We refactored the template TestCase object so that when its instantiated, you have a method called 'testExample.vit' (whereas it used to instantiate testExample.vi). The VI Tester frameworks is 'smart' enough to know that .vit files are not meant to be run as tests, so they are not added to the tree. To create a test, right click on the the 'testExample.vit' file and select 'New Method from Template'. Create a name for this method such as 'testXXX.vi' where XXX where XXX is anything you want (example: 'testVITesterUI.vi'). Now that the TestCase actually contains a test, the class will show up on the tree. That should get you past the roadblock. Another option is to open the example project (Help-->Open Example Project) and that will also work.
  18. Sorry that you're still having trouble. What are your default language settings? It could be a localization issue. My last suggestion if you have time to check this - try downgrading VI tester to the previous version from VIPM (restart LabVIEW after installation) and see if that works. I'll try to reproduce your issue at work tomorrow (Monday).
  19. Try saving the .lvproj file and seeing if the tests appear (relaunch VI Tester UI after saving .lvproj file).
  20. Hi Bastian, Thanks for investigating and posting this info. I'm glad you are able to open the VI Tester UI (and luckily, the two cases that do run are probably the most common cases). I've added this issue to our known issues list (Case 10911). Let us know if you have any other issues! Thanks, Omar
  21. Thanks for reporting this bug so clearly! I was able to easily reproduce the bug and have added it to the known issues list (Case 10909).
  22. Hi Bastian, Here's what I found: If I run VI Tester from the menu of the Getting Started Window, I get the same error as you (1004, same dialog text) - this only happened when I changed the regional/language settings to German, so I suspect it is a localization issue - I will add this to our known issues shortly. However, if I open a new project window and press the VI Tester button: the VI Tester GUI opens up without an issue. Did you try this? Also, when it opens the first time, it asks you if you want to recompile the code in LV2010. Select yes. After this, you should be able to open VI Tester faster and more reliably. I still wouldn't recommend opening it from the Getting Started Window though. Let me know if you're still having launch issues. One other question - in your localization of LabVIEW, is there a folder called: [Program Files]\LabVIEW 2010\resource or does it have another name? Can you copy/paste what that full path looks like? Thanks, Omar
  23. Thanks Bastian, I'll see if I can reproduce the issue and get back to you.
  24. Hi Basti, Thanks for your patience. I will try to reproduce the problem. What localization settings are you using (regional settings/language options)? What version of Windows are you using? Thanks, Omar
  25. There had been an issue (that seemed to be resolved in LV2009) where it was not possible to launch VI Tester from the Getting Started Window. It's possible that this is what you are seeing. Try opening a new project file or a blank VI and then launching VI Tester and see if that works. It may be a localization issue for German LabVIEW versions. Please reply once you've tested this (even if it works).
  • Create New...

Important Information

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