Unit tests

[e-koch]

Once we have the basic workflow going, we need some tests of the code.

Two options

• have test suite that we run locally for any change.
• use Travis or another CI service. The issue with that is the 1 Gb install for CASA and I'm not sure if they limit the storage. The Spectral-cube project has been avoiding this, and I think CARTA only needs casacore (@low-sky?) so it may not be worth it.

Once tests are in place, committing directly to this repo will be disabled and work will be done on our own forks. To make changes here, all changes will have to pass the tests.

[e-koch]

We'll also need testing data. Probably easiest to generate simulated data as part of the test suite.

[radioastronomer]

Hi All,

I'm not much used to GitHub workflows...

My suspicion is that the easiest thing to do would be to have a
test-server no AWS and then commit changes from there when tests are passed.

Sincerely,

Greg

Gregory R. Sivakoff
Assistant Professor of Physics
University of Alberta, Edmonton, AB
sivakoff@ualberta.ca

On 2015-09-28 10:24 AM, Eric Koch wrote:

Once we have the basic workflow going, we need some tests of the code.

Two options

• have test suite that we run locally for any change.
• use Travis or another CI service. The issue with that is the 1 Gb
  install for CASA and I'm not sure if they limit the storage. The
  Spectral-cube project has been avoiding this, and I think CARTA
  only needs casacore (@low-sky https://github.com/low-sky?) so it
  may not be worth it.

Once tests are in place, committing directly to this repo will be
disabled and work will be done on our own forks. To make changes here,
all changes will have to pass the tests.

—
Reply to this email directly or view it on GitHub
#1.

[e-koch]

Travis will essentially do the same thing (and it's already automated). But if we need more flexibility, I agree that testing on AWS would be the way to go.

[low-sky]

The problem I see with Travis is that it spins its own VMs on a build trigger (like a commit). Since this project explicitly depends on CASA, naively this means pulling it over each time. This will probably fail on Travis and may piss off the people hosting the CASA images (NRAO). I think this might be a case where simple is better: build a test suite and run it manually before making major commits.

@astrilet suggests that you could build a docker image with CASA, host it on dockerhub, and cache the image on CircleCI. He likes this because there is a VM that will persist a little while. He also thinks it might work to cache CASA directly on CircleCI. TravisCI has a cache service but only for private repos.

[e-koch]

Ah, that sounds nicer. I have docker builds mostly ready so I'll check this out soon.