Take the 2-minute tour ×
Mathematica Stack Exchange is a question and answer site for users of Mathematica. It's 100% free, no registration required.

I am in the process of writing a package, but my way of testing it just seems wrong and inefficient. Each time I edit the .m file, I save it, quit the kernel, call the package in a separate notebook and proceed to test.

Is there a more efficient way to test a package without having to save/quit kernel/rerun everything??


share|improve this question
Have a look at the Workbench. –  b.gatessucks Aug 16 '14 at 15:17
<<myFile.m or Get["myFile.m"] –  user21 Aug 16 '14 at 20:22

2 Answers 2

up vote 3 down vote accepted

You can just add something like

ClearAll["MyPackage`*", "MyPackage`*`*"]

to the beginning of the package. Then you don't have to restart the kernel, just re-load the package the most convenient possible way (<<mypackage.m or if you edit it in the front end, then simply re-run it).

You need to be more cautious if your package maintains some sort of internal state or if it dynamically adds definitions to symbols (e.g. closures).

share|improve this answer
This is the way to go. One small suggestion: In a package you either have functions that are exported or those that are local. I'd put the ClearAll in the package before the local function. That way anyone who uses the package can just Get it and does not need to know that a ClearAll should be called first. –  user21 Aug 17 '14 at 6:35

This is how I do it assuming that your package has an exported function called myExportedGUIOrFunctionTestScript. Everytime you click on the button the package is loaded and the results of your test function is placed in a new notebook. This approach has benefits and weaknesses. I'll let the community help on the evaluation of this solution.

myExportedGUIOrFunctionTestScript := "myPkgFunction tested on " <> DateString[]

nbCmd[Button["Reload My Package",
      "WolframWorkspaces\\base\\myPkg\\myPkg"}, "myPkgMFile.m"]];
   bvnb = CreateDocument[myExportedGUIOrFunctionTestScript]
   , Method -> "Queued"
  , Saveable -> False
  , WindowSize -> All
  , WindowMargins -> {{Automatic, 0}, {Automatic, 0}}
  , WindowTitle -> "Testing My Package"

Other users may argue that the Workbench has a formal way of testing functions. The reason why I don't use it is because somethimes that formal process may get "out-of-synch" and there is no way to know about that but after you get tired of "fixing" your code. So, my experience has driven me to do things this way.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.