11
$\begingroup$

I've been dealing with bugs in a very ad hoc fashion, mostly hitting them as they come or trying to write a note in my code to deal with them.

As my codebase has broken the 50000 loc mark I find it's harder and harder to remember all my little issues and ideas, so I want to add a testing framework and bug tracker to my application dev suite. Problem is I'm unsure the best way to track bugs in an application (the testing will obviously just hook into "MUnit`", following Jason B's usage pattern).

It's relevant to note that I do all of my work entirely within the FE (thanks to Kuba for pointing out that this is worth mentioning). Because of this unless you think I am being entirely unreasonable (let me know if you do), I would really prefer not to have to open another program to log these bugs or TODO notes.

What is an effective way to tackle this problem?

My only thing is that I would strongly prefer to have it in pure Mathematica so that I can easily link the framework into my existing code base.

Can anyone convince me of the sheer ridiculousness of this or suggest a minimal prototype for a simple, extensible, programmable version of this?

$\endgroup$
4
  • 1
    $\begingroup$ Since you keep it on github, aren't 'issues' good enough? $\endgroup$
    – Kuba
    Commented Jun 14, 2018 at 7:53
  • $\begingroup$ @Kuba it's a bit inconvenient to have to open a new issue myself for something as simple as, e.g., "DeploymentInfo ill-formatted" (a bug I recently wrote down in a notebook where I'm trying to track them). It'd be nice to just open a little window, fill out a template, and have it automatically added to either a notebook or little database of bugs I store in some undeployed part of my project. $\endgroup$
    – b3m2a1
    Commented Jun 14, 2018 at 7:55
  • $\begingroup$ Maybe it is worth mentioning obvious alternatives you've discarded. Another one is that IDEs have fancy support for TODO lists. Unless you are working purely in FE (which is the case I think). $\endgroup$
    – Kuba
    Commented Jun 14, 2018 at 7:58
  • $\begingroup$ @Kuba Good point. I should note that I do my work completely in the FE and would prefer not to have to leave it to do this. $\endgroup$
    – b3m2a1
    Commented Jun 14, 2018 at 7:59

1 Answer 1

2
$\begingroup$

I've been working on this off-and-on for a bit, but here's what I currently have: https://github.com/b3m2a1/BugTracker

It's a little paclet that supports making a bug-tracker notebook and pushing that to a Dataset or list of bugs.

I need to figure out exactly what I want to do with this still, but here's an excerpt from the README of that package.

Usage

This bug tracker currently only supports converting to-and-from a formatted bug notebook to a list of bugs / bug dataset.

To start, create a new bug notebook:

<<BugTracker` 
 NewBugsNotebook[$TemporaryDirectory]

(*Out:*)

readme-7075886137484081466

readme-5009766874165003355

Then click the "Add Bug" button to create a popup window to add info on the new bug:

readme-445044655558372174

After adding parameters a new entry will be added at the bottom of the notebook:

readme-5919741057952872355

You can see the parameters in there. The empty square is a check-box to mark resolved bugs. Here's an example of this in action:

readme-3342069607634808987

We can convert these bugs to a list of BugObjects or a Dataset . We can either use the buttons in the docked menu to export to a file or the buttons below the search interface to write into the notebook. Here's what appears if we write the bug list to the notebook:

readme-4431207052699221141

More work to make using these BugObjects more convenient is in the pipeline and suggestions are welcome.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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