Confirming best practices when running packages specs (ie tests)


I just want to confirm that the workflow I describe below is the best one to run test/specs when writing an Atom package.

  1. Here is a simple test (from a package that I’m going to send PR for)

  1. to run it, I go to: View / Developer / Run Package Specs

  1. a window called Spec Suite is opened (aligned bellow to the Atom editor)

  1. I make a change to the source code (‘AAAAAAA’ below)

  1. Type Cmd+S to save the type

  2. Move the mouse to the Reload Specs button (inside the Spec Suite window)

  1. Click on the Reload Specs button

  2. Wait for the result to show up

  1. Fix the code

10.)Type Cmd+S to save the type

  1. Move the mouse to the Reload Specs button (inside the Spec Suite window)

  1. Click on the Reload Specs button

13 Wait for the result to show up

My problem with this work flow is that it has too many steps.

What I would like to have (and used to have when coding in C# with NCrunch), is something like:

  1. Make a code change
  2. Lift my fingers up (i.e. don’t type for a couple seconds)
  3. See the test execution result (including the code coverage)

My first question is: Is the workflow described above the best-practices one?, or are there other packages or techniques that I should be using (like maybe saveallthetime )

The second question is: Is there a way to achieve the ‘auto test execution’ workflow? , with tests executed automatically, and code coverage visualised (as seen in lcov-info)



It is the general workflow, yes. I generally just do:

  1. Edit the code
  2. Save the code
  3. Press the key combination for run specs (I have it mapped to Cmd+Alt+T)
  4. Read the results
  5. Press the key combination to close the spec window Cmd+W (I don’t believe this is strictly necessary)
  6. Repeat as necessary

While I generally have the kind of tools you’re talking about for non-Atom projects (though I wouldn’t want the triggered-by-inactivity one), I don’t know of them being available for Atom yet.

I’m also not generally a fan of code coverage (unless it is arc or branch coverage, but those tools are so rarely available) … but that is probably not really relevant … :grinning:


Thanks (its good that I’m not missing something major)

Well I’m a bit fan of Code Coverage, as you can see on Achieving 98% Code Coverage, by running mocha Web Automation Tests in Chrome (from WebStorm) and The quest for 100% Code Coverage, the 96cc idea and ‘apps with low CC must be insure’.

Which leads me to my next question: “Are there special gotchas on running code coverage on a packaged code?”

This is how I usually do for my mocha based projects, is there a similar workflow for Atom?

Here is an hack that I was playing with for the atom-lcov-info package

How can I find the code coverage of atom tests?
Code coverage on Atom package specs
Off-Topic: Thoughts on Code Coverage