Sign up ×
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

3 Answers 3

up vote 5 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


Some time ago, I wrote a package specifically to address this issue. It is named PackageManipulations and described in this post. The package can be imported as


It has an accompanying notebook with detailed explanations of how to use it, but I will give a brief summary here.

PackageManipulations package

The main functions in the package are PackageClear, PackageClearComplete, PackageReload, and PackageRemove. They do what they say.

Reloading the package



to reload your package. Note that PackageReload calls PackageClearComplete (described below), and thus clears previous definitions that symbols in your package's context and its sub-contexts may have had (but does not remove the symbols). Thus, this should be the most frequently used tool in the context of package testing.

You may call

PackageReload[your-package-context, KillShadowing -> True]

if you want to resolve some existing shadowing conflict in favor of the symbol in the package being reloaded - the other symbol will then be Removed.

Clearing the symbols in the package without removing them.

If you just want to clear all the names of all symbols in the context of your package, but keep the package' s context and symbol names in the system, you can call


To clear (but not remove) the context together with all sub - contexts, use


Removing the package from the system

To remove the context and all its sub-contexts, use PackageClearComplete with the RemovePackage -> True option :

PackageClearComplete[your-package-context, RemovePackage -> True]

A somewhat lower-level function to remove all package symbols and the entire package from the system is PackageRemove:


It Removes all the symbols in the specified context, and also removes the context from $ContextPath and $Packages, if it is there. It does not, however, deal with sub-contexts, so the proper way to completely remove the package from the system is to call PackageClearComplete with the RemovePackage -> True option, as mentioned above.

Note that removal is not an innocent operation, since all definitions outside the package being removed, which referenced some of the symbols in the package, will be permanently invalidated, until those definitions themselves are reloaded. Clearing definitions but keeping the symbols does not lead to this issue.


The linked notebook contains more detailed explanations and examples.

The package is rather old, and may not work in some cases. If something does not work, let me know, and I will make sure to fix the issue.

share|improve this answer

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.