benjaminhysell

[cross posted: http://forums.jkisoft.com/index.php?showtopic=1022, not sure what the etiquette is here and if it belongs here or there] Goal: Create a set of packages that I can distribute to my team that we will use to start off every new project. Scenarios: I have a set of base classes that we are going to inherit from to generate new code for each new project. As an example, I have a database class. This class has all of the features to allow one to create, read, update, and delete (typical CRUD) and item to move into our out of the database. This base class describes the functionality and provides the API for the rest of the application to call, and based on the object supplied it will perform the proper operation on the database. This separation also allows for unit testing of the database interactions...I can mock out the database calls during the testing phase of the project if there is a common API for all CRUD for every object going in and out of the database. Motivation: In my world, the developer has a framework of where to put their CRUD and what VIs they need to overwrite to get their item into our out of the database. Now we have a framework where any developer on the project comes in, opens up someone else's code and goes 'where is the update call for foo1', they goto the class for 'foo1' and lookup the update.vi that has been overriden from the parent class. Each item that goes into our out of the database has their own CRUD VIs, since each item is different and needs to be inserted and queried from the database in different ways. Question: What is the best practice to inherit in a project a class that lives in a package? I have found through playing around I cannot inherit from a class in a package, that I actually need to create a VI (I've been calling it 'includes.vi') lay down a reference to the class in the package, and then I can inherit from it in the project. Is there a better way? Is this a common use of the Package methodology? Would I be better off sending out Project Libraries to my developers?

QUOTE (jdunham @ Feb 18 2009, 03:12 PM) This is a great little library, but one issue I'm having that I'm not sure if what I am seeing is the proper behavior. I'm using conditional disables to do unit testing with...so in my unit test I will set a conditional disable then run the unit test. Right now my project has one setting, SendEmail, and I am toggling it between true and false. When I run my unit test, I use your vilib to set the SendEmail = true, however when I watch my vi as it runs the false conditional disable case runs on the first run through. If I run the unit test again this time the conditional disable will run the true case. It appears that what ever the conditional disable symbol that is set to before I start a run is the one that is actually executed, however if you look at the block diagram this isn't the case. i.e. the conditional disable I want to run is actually 'enabled' yet doesn't run. Thoughts? -ben

QUOTE (Jim Kring @ Feb 2 2009, 08:58 PM) I thought I would poke this thread and see if we can get it started again... In the past six years doing TDD I've only actually unit tested a handful of private class methods, I would say less than four. I subscribe to what I feel is the overall tone of this thread, we shouldn't be testing private methods for all of the reasons given above. However, that said, I agree with Jim, if I know what I am getting into there should be a method to unit test private methods. In VS2008 you can do it, however they really make you really work for it, there is a whole dance you need to go through with reflection to load the assembly and to unit test it. It is a pain, but it can be done. I think as VI Tester goes forward it would be nice to have the option, but an option that has a cost to the developer. Inflicting this cost would make a developer think twice about wanting to actually do the unit testing this way, and may in turn cause them to refactor their code to a cleaner implementation if at all possible.

QUOTE (Paul_at_Lowell @ Feb 19 2009, 11:44 AM) Excellent! I was through those links in the past, but I suppose I did not dig deep enough :-). A shortcut: http://wiki.lavag.org/Set_up_differencing_capabilities Just tried it out with 8.6.1, everything works great! -ben

Hey everyone, I was able to use: http://expressionflow.com/2007/08/28/using...th-tortoisesvn/ and integrated SVN with the merge command, and it works great! What about using the Diff command from Tortoise SVN Windows client? I've googled around a bit and found an application called 'lvdiff', but I haven't seen any recent activity on the project since 2005. Has LVMerge replaced lvdiff? If so, has anyone figured out how to configure Tortoise to use LVMerge when attempting to diff a vi? Thanks! -ben