Monday, March 12, 2012

Lesson 2: IntegratedTests, IntegratedTests and more IntegratedTests

Why Integrated Tests?
One of the biggest goals I had in the development of the latest version of FlexiDesign was to ramp up the number of automated tests that run as part of our build system. And I am talking about Integrated Tests not unit or functional (those are important too, of course). I far prefer Integrated Tests primarily because it checks the full product from beginning to end.


Integrated Tests of a CAD add-in? Really?
But how do you test a product that is an add-in to a CAD system? The CAD system controls when the add-in product is loaded and when it is available to the end-user to interact with through a UI. It is not an easy task to simulate all these actions in an automated test (something that runs with no developer/user interaction whatsoever).


But there is a way.


So what is the solution?
If you have read my previous blog posts, then you may have found one of my downloads SWXBATCH_CEEFIT which couples the open source Integrated Test Framework (CEEFIT) with a simple wrapper to start SWX, call some SWX API, verify the output using CEEFIT, and then stop SWX. If you are interested, then read that article or even email me at ganeshram iyer [at] gmail dot com.


You can download the framework here:
http://ossandcad.googlecode.com/files/swxbatch_ceefit_6_16_2009.zip 
Or you can browse the source code here:
https://ossandcad.googlecode.com/svn/trunk/swxbatch_ceefit
Extending SWXBATCH_CEEFIT
The download assumes that you have SolidWorks already installed at a specific path (I think it is C:\Program Files\SolidWorks). This is important, because SolidWorks registers its API in the Windows Registry and SWXBATCH_CEEFIT relies on that registration to call the SWX API over COM.


By default SWXBATCH_CEEFIT calls SolidWorks 2009, but making it call other versions of SolidWorks is pretty easy too:

  • Simply change the headers that you #include in SWX.cpp
  • If you want to build against multiple SWX versions, then create a new configuration in the project, add a preprocessor definition and use that to #ifdef which SWX headers to #include. e.g.:
    #ifdef SWX2011
    #include "swx2011\amapp.h"
    #include "swx2011\swpublished_i.h"
    #include "swx2011\swconst.h"
    #else
    // Solidworks includes for e.g. 2009
    #include "amapp.h"
    #include "swpublished_i.h"
    #include "swconst.h"
    #endif

    •  Of course you need to have the specific version of SWX installed too :)
    SWXBATCH_CEEFIT also needs a valid SWX License to run, since it actually starts SWX to "do its business".

    Summary
    SWXBATCH_CEEFIT runs on 32-bit, 64-bit, Windows XP, Vista, and 7, SolidWorks 2009, 2010, 2011, 2012. So the coverage of test platforms and OS is pretty comprehensive, though the limitation is that the specific SWX version itself needs to run on the OS - you may have to check with SWX support to determine those details. You may have to add some configurations yourself though (or email me and I can send you the latest version I have that has all the required settings).

    We use this to test the ins and outs of FlexiDesign and it dramatically helps improve the stability of the product. We run Integrated Tests on FlexiDesign every night - it takes a few hours to run the entire thing due to all the combinations tested - and we only need to edit/add the tests when we have a design change that changes the behavior of the product - which is primarily on major functionality change or major feature addition or major bug change (read: not often).

    In short, if you develop CAD Addins (viz. SolidWorks), try out SWXBATCH_CEEFIT and let me know if you find it useful. We certainly do.

                                Sunday, March 11, 2012

                                Solution for "Windows Scripting Host: Can't find a script engine 'javascript'"

                                Problem
                                Using TortoiseSVN's 'Edit Conflicts' on conflicts in DOCX files, used to throw up a message box with a text similar to:
                                Windows Script Host: Can't find a script engine "javascript" for C:\Program Files\TortoiseSVN\Diff-Scripts\merge-docx.js
                                Solution
                                To solve this problem, I initially thought the problem was with TortoiseSVN. Was I barking up the wrong tree!

                                Turns out that the problem is related to Windows Script Host and the solution is much simpler:

                                1. Open a Command Prompt with Administrative privileges (cmd)
                                2. Simply enter

                                  regsvr32 jscript.dll
                                3. There isn't a 3rd step :-)
                                Blogging my solution as I didn't find a straight forward answer to my problem. Hope you find it useful.

                                Friday, November 18, 2011

                                Lesson 1: Licensing is part of Software Engineering


                                For the better part of this year, 2011, I was involved in the commercial release of a novel 2D to 3D conversion software, FlexiDesign. During the development, test and release to manufacturing (RTM) of FlexiDesign I picked up a few nuggets of knowledge and experience that I don't hear being discussed often, especially in this cloud-centric world. Perhaps it was discussed fervently a decade or two ago when desktop technologies were cool, but still relevant today since not all technologies are ready for the cloud (just yet).

                                One of the lessons I learned during the final development sprint was how important it is to incorporate the requirements of a License Manager early in the development cycle.

                                Briefly (for the impatient):

                                1. The License Manager requirements should be considered as part of the rest of your Software Engineering tasks
                                2. The License Manager should support Network Licenses
                                3. The License Manager must be customizable (preferably through API)
                                4. The License Manager should support DLLs in addition to EXEs
                                5. The License Manager should preferably be the same as the host CAD system
                                In Detail (for those of you who are still reading):
                                1. The License Manager is part of Software Engineering
                                  While most desktop applications can incorporate an off-the-shelf License Manager, the requirement has to be dealt with more carefully when you are developing CAD Add-Ins. While you can simply bolt on many License Managers on to a regular non-add-in product, it may not be possible to do so with CAD add-in products, since the CAD system may need to talk some parts of your product without any limitations and you want to protect/lock other parts of you product. For example to register an add-in with  SolidWorks, you need to make sure that the ConnectToSW(), DisconnectFromSW(), RegisterFunction() and UnregisterFunction() are not locked away by your License Manager. Else your add-in may not load at all.
                                2. The License Manager should support Network Licenses
                                  Another requirement that has high priority is the availability of Network Licenses. CAD Administrators don't want to maintain separate licenses per PC, since that is very inefficient and time consuming. So the License Manager you select must be available over the network for your add-in to connect to validate the license. This also limits the potential candidates of License Managers leaving you with even fewer choices.
                                3. Customizable License Manager (preferably through API) AND
                                4. License Manager should support DLLs
                                  With FlexiDesign, we realized that the default behavior of most License Managers is to prevent the licensed software from running. With CAD systems, add-ins are loaded on startup and preventing the DLL from loading (e.g. if the license for your product has expired) might prevent the CAD system from starting up - which most people may agree is not a good thing.
                                5. Same License Manager as the host CAD
                                  If at all possible, your License Manager should be the same as the the one your CAD system uses. This is not normally possible, but if you build for Pro/Engineer then I believe they use FlexLM License Manager (http://www.flexerasoftware.com/products/software-licensing.htm). SolidWorks seems to use an in-house build License Manager - SolidNetWork License Administrator (if I got the name right). 
                                So after all those details, the License Manager we selected for FlexiDesign is ........ for me to know and you to find out. Sorry. Can't reveal company information.

                                If you are interested in cracking software licenses, then I found a nice starter article at http://www.zabkat.com/blog/30Jul11-dummy-software-cracks.htm, though I don't personally recommend such possibly illegal activities.