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: 
Or you can browse the source code here:
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"
    // Solidworks includes for e.g. 2009
    #include "amapp.h"
    #include "swpublished_i.h"
    #include "swconst.h"

    •  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".

    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'"

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