From 9fe5b1082aeadca1bb7e779bb9802af1fb9c1407 Mon Sep 17 00:00:00 2001 From: Aashish Chaudhary Date: Sun, 7 Jun 2015 21:55:09 -0400 Subject: [PATCH 1/8] Initial import --- DEVELOP.md | 374 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 374 insertions(+) create mode 100644 DEVELOP.md diff --git a/DEVELOP.md b/DEVELOP.md new file mode 100644 index 0000000000..008e64a2ec --- /dev/null +++ b/DEVELOP.md @@ -0,0 +1,374 @@ +Contributing to UV-CDAT +====================== + +Where to start? +--------------- + +All contributions, bug reports, bug fixes, documentation improvements, +enhancements and ideas are welcome. + +If you are simply looking to start working with the *UV-CDAT* codebase, +navigate to the [GitHub "issues" +tab](https://github.com/UV-CDAT/uvcdat/issues) and start looking through +interesting issues. + +Feel free to ask questions on [mailing +list](uvcdat-users@llnl.gov) + +Bug Reports/Enhancement Requests +-------------------------------- + +Bug reports are an important part of making *UV-CDAT* more stable. Having +a complete bug report will allow others to reproduce the bug and provide +insight into fixing. Since many versions of *UV-CDAT* are supported, +knowing version information will also identify improvements made since +previous versions. Often trying the bug-producing code out on the +*master* branch is a worthwhile exercise to confirm the bug still +exists. It is also worth searching existing bug reports and pull +requests to see if the issue has already been reported and/or fixed. + +Bug reports must: + +1. Include a short, self-contained Python snippet reproducing the + problem. You can have the code formatted nicely by using [GitHub + Flavored + Markdown](http://github.github.com/github-flavored-markdown/): : + + ```python + >>> import vcs + >>> vcs.init() + ... + ``` + +2. Explain why the current behavior is wrong/not desired and what you + expect instead. + +The issue will then show up to the *UV-CDAT* community and be open to +comments/ideas from others. + +Working with the code +--------------------- + +Now that you have an issue you want to fix, enhancement to add, or +documentation to improve, you need to learn how to work with GitHub and +the *UV-CDAT* code base. + +### Version Control, Git, and GitHub + +To the new user, working with Git is one of the more daunting aspects of +contributing to *UV-CDAT*. It can very quickly become overwhelming, but +sticking to the guidelines below will make the process straightforward +and will work without much trouble. As always, if you are having +difficulties please feel free to ask for help. + +The code is hosted on [GitHub](https://www.github.com/UV-CDAT/uvcdat). To +contribute you will need to sign up for a [free GitHub +account](https://github.com/signup/free). We use +[Git](http://git-scm.com/) for version control to allow many people to +work together on the project. + +Some great resources for learning git: + +- the [GitHub help pages](http://help.github.com/). +- the [NumPy's + documentation](http://docs.scipy.org/doc/numpy/dev/index.html). +- Matthew Brett's + [Pydagogue](http://matthew-brett.github.com/pydagogue/). + +### Getting Started with Git + +[GitHub has instructions](http://help.github.com/set-up-git-redirect) +for installing git, setting up your SSH key, and configuring git. All +these steps need to be completed before working seamlessly with your +local repository and GitHub. + +### Forking + +You will need your own fork to work on the code. Go to the [UV-CDAT +project page](https://github.com/UV-CDAT/uvcdat) and hit the *fork* +button. You will want to clone your fork to your machine: : + + git clone git://github.com/UV-CDAT/uvcdat.git UV-CDAT-yourname + cd UV-CDAT-yourname + git remote add myuvcdat git@github.com:your-user-name/uvcdat.git + +This creates the directory UV-CDAT-yourname and connects your repository +to the upstream (main project) *UV-CDAT* repository. + +You will also need to hook up Travis-CI to your GitHub repository so the +suite is automatically run when a Pull Request is submitted. +Instructions are +[here](http://about.travis-ci.org/docs/user/getting-started/). + +### Creating a Branch + +You want your master branch to reflect only production-ready code, so +create a feature branch for making your changes. For example: + + git branch shiny-new-feature + git checkout shiny-new-feature + +The above can be simplified to: + + git checkout -b shiny-new-feature + +This changes your working directory to the shiny-new-feature branch. +Keep any changes in this branch specific to one bug or feature so it is +clear what the branch brings to *UV-CDAT*. You can have many +shiny-new-features and switch in between them using the git checkout +command. + +### Making changes +Before making your code changes, it is often necessary to build the code +that was just checked out. There are two primary methods of doing this. + +The best way to develop *UV-CDAT* is to build using default settings: + + mkdir uvcdat-build + cmake uvcdat-path-to-source + make -jN + + If you startup the Python interpreter in the *UV-CDAT* source + directory you will call the built C extensions + +Contributing to the documentation +--------------------------------- + +If you're not the developer type, contributing to the documentation is +still of huge value. You don't even have to be an expert on *UV-CDAT* to +do so! Something as simple as + +Contributing to the code base +----------------------------- +### Code Standards + +*UV-CDAT* uses the [PEP8](http://www.python.org/dev/peps/pep-0008/) +standard. There are several tools to ensure you abide by this standard. + +Alternatively, use [flake8](http://pypi.python.org/pypi/flake8) tool for +checking the style of your code. Additional standards are outlined on +the [code style wiki +page](LINK HERE). + +Please try to maintain backward-compatibility. *UV-CDAT* has lots of +users with lots of existing code, so don't break it if at all possible. +If you think breakage is required clearly state why as part of the Pull +Request. Also, be careful when changing method signatures and add +deprecation warnings where needed. + +### Test-driven Development/Writing Code +*UV-CDAT* is serious about [Test-driven Development +(TDD)](http://en.wikipedia.org/wiki/Test-driven_development). This +development process "relies on the repetition of a very short +development cycle: first the developer writes an (initially failing) +automated test case that defines a desired improvement or new function, +then produces the minimum amount of code to pass that test." So, before +actually writing any code, you should write your tests. Often the test +can be taken from the original GitHub issue. However, it is always worth +considering additional use cases and writing corresponding tests. + +Adding tests is one of the most common requests after code is pushed to +*UV-CDAT*. It is worth getting in the habit of writing tests ahead of +time so this is never an issue. + +#### Writing tests + +All tests should go into the *tests* subdirectory of the specific +package. There are probably many examples already there and looking to +these for inspiration is suggested. + +The `UV-CDAT.util.testing` module has many special `assert` functions +that make it easier to make statements about whether Series or DataFrame +objects are equivalent. The easiest way to verify that your code is +correct is to explicitly construct the result you expect, then compare +the actual result to the expected correct result: + + def test_pivot(self): + data = { + 'index' : ['A', 'B', 'C', 'C', 'B', 'A'], + 'columns' : ['One', 'One', 'One', 'Two', 'Two', 'Two'], + 'values' : [1., 2., 3., 3., 2., 1.] + } + + frame = DataFrame(data) + pivoted = frame.pivot(index='index', columns='columns', values='values') + + expected = DataFrame({ + 'One' : {'A' : 1., 'B' : 2., 'C' : 3.}, + 'Two' : {'A' : 1., 'B' : 2., 'C' : 3.} + }) + + assert_frame_equal(pivoted, expected) + +#### Running the test suite + +The tests can then be run directly inside your build tree by typing:: + + ctest + +To save time and run tests in Pararallel + + ctest -jN + +The tests suite is exhaustive and takes around 20 minutes to run. Often +it is worth running only a subset of tests first around your changes +before running the entire suite. This is done using one of the following +constructs: + + ctest -R test-name + ctest -R regex* + +#### Running the performance test suite + +TODO + +### Documenting your code + +TODO + +Contributing your changes to *UV-CDAT* +------------------------------------- + +### Committing your code + +Keep style fixes to a separate commit to make your PR more readable. Once you've made changes, you can see them by typing: + + git status + +If you've created a new file, it is not being tracked by git. Add it by +typing : + + git add path/to/file-to-be-added.py + +Doing 'git status' again should give something like : + + # On branch shiny-new-feature + # + # modified: /relative/path/to/file-you-added.py + # + +Finally, commit your changes to your local repository with an +explanatory message. An informal commit message format is in effect for +the project. Please try to adhere to it. Here are some common prefixes +along with general guidelines for when to use them: + +> - ENH: Enhancement, new functionality +> - BUG: Bug fix +> - DOC: Additions/updates to documentation +> - TST: Additions/updates to tests +> - BLD: Updates to the build process/scripts +> - PERF: Performance improvement +> - CLN: Code cleanup + +The following defines how a commit message should be structured. Please +reference the relevant GitHub issues in your commit message using GH1234 +or \#1234. Either style is fine, but the former is generally preferred: + +> - a subject line with \< 80 chars. +> - One blank line. +> - Optionally, a commit message body. + +Now you can commit your changes in your local repository: + + git commit -m + +If you have multiple commits, it is common to want to combine them into +one commit, often referred to as "squashing" or "rebasing". This is a +common request by package maintainers when submitting a Pull Request as +it maintains a more compact commit history. To rebase your commits: + + git rebase -i HEAD~# + +Where \# is the number of commits you want to combine. Then you can pick +the relevant commit message and discard others. + +### Pushing your changes + +When you want your changes to appear publicly on your GitHub page, push +your forked feature branch's commits : + + git push origin shiny-new-feature + +Here origin is the default name given to your remote repository on +GitHub. You can see the remote repositories : + + git remote -v + +If you added the upstream repository as described above you will see +something like : + + origin git://github.com/UV-CDAT/uvcdat.git + myuvcdat git@github.com:yourname/uvcdat.git (fetch) + myuvcdat git@github.com:yourname/uvcdat.git (fetch) + +Now your code is on GitHub, but it is not yet a part of the *UV-CDAT* +project. For that to happen, a Pull Request needs to be submitted on +GitHub. + +### Review your code + +When you're ready to ask for a code review, you will file a Pull +Request. Before you do, again make sure you've followed all the +guidelines outlined in this document regarding code style, tests, +performance tests, and documentation. You should also double check your +branch changes against the branch it was based off of: + +1. Navigate to your repository on + GitHub--. +2. Click on Branches. +3. Click on the Compare button for your feature branch. +4. Select the base and compare branches, if necessary. This will be + master and shiny-new-feature, respectively. + +### Finally, make the Pull Request + +If everything looks good you are ready to make a Pull Request. A Pull +Request is how code from a local repository becomes available to the +GitHub community and can be looked at and eventually merged into the +master version. This Pull Request and its associated changes will +eventually be committed to the master branch and available in the next +release. To submit a Pull Request: + +1. Navigate to your repository on GitHub. +2. Click on the Pull Request button. +3. You can then click on Commits and Files Changed to make sure + everything looks okay one last time. +4. Write a description of your changes in the Preview Discussion tab. +5. Click Send Pull Request. + +This request then appears to the repository maintainers, and they will +review the code. If you need to make more changes, you can make them in +your branch, push them to GitHub, and the pull request will be +automatically updated. Pushing them to GitHub again is done by: + + git push -f myuvcdat shiny-new-feature + +This will automatically update your Pull Request with the latest code +and restart the Travis-CI tests. + +### Delete your merged branch (optional) + +Once your feature branch is accepted into upstream, you'll probably want +to get rid of the branch. First, merge upstream master into your branch +so git knows it is safe to delete your branch : + + git fetch origin + git checkout master + git reset --hard origin/master + +Then you can just do: + + git branch -d shiny-new-feature + +Make sure you use a lower-case -d, or else git won't warn you if your +feature branch has not actually been merged. + +The branch will still exist on GitHub, so to delete it there do : + + git push origin --delete shiny-new-feature + + + + + + From 395a21256ee66c44defbf0a52e5fb06182f8385f Mon Sep 17 00:00:00 2001 From: Aashish Chaudhary Date: Sun, 7 Jun 2015 22:03:40 -0400 Subject: [PATCH 2/8] Fixed test example code --- DEVELOP.md | 50 ++++++++++++++++++++++++++------------------------ 1 file changed, 26 insertions(+), 24 deletions(-) diff --git a/DEVELOP.md b/DEVELOP.md index 008e64a2ec..8a640de980 100644 --- a/DEVELOP.md +++ b/DEVELOP.md @@ -10,7 +10,7 @@ enhancements and ideas are welcome. If you are simply looking to start working with the *UV-CDAT* codebase, navigate to the [GitHub "issues" tab](https://github.com/UV-CDAT/uvcdat/issues) and start looking through -interesting issues. +interesting issues. Feel free to ask questions on [mailing list](uvcdat-users@llnl.gov) @@ -91,7 +91,7 @@ button. You will want to clone your fork to your machine: : git clone git://github.com/UV-CDAT/uvcdat.git UV-CDAT-yourname cd UV-CDAT-yourname git remote add myuvcdat git@github.com:your-user-name/uvcdat.git - + This creates the directory UV-CDAT-yourname and connects your repository to the upstream (main project) *UV-CDAT* repository. @@ -136,7 +136,7 @@ Contributing to the documentation If you're not the developer type, contributing to the documentation is still of huge value. You don't even have to be an expert on *UV-CDAT* to -do so! Something as simple as +do so! Something as simple as Contributing to the code base ----------------------------- @@ -175,30 +175,32 @@ time so this is never an issue. All tests should go into the *tests* subdirectory of the specific package. There are probably many examples already there and looking to -these for inspiration is suggested. +these for inspiration is suggested. -The `UV-CDAT.util.testing` module has many special `assert` functions -that make it easier to make statements about whether Series or DataFrame -objects are equivalent. The easiest way to verify that your code is -correct is to explicitly construct the result you expect, then compare -the actual result to the expected correct result: +The `testing.checkimage.py` module has special `check_result_image` function +that make it easier to check whether plot produced after data extraction and +transformation are equivalent to baseline. For an example see below: - def test_pivot(self): - data = { - 'index' : ['A', 'B', 'C', 'C', 'B', 'A'], - 'columns' : ['One', 'One', 'One', 'Two', 'Two', 'Two'], - 'values' : [1., 2., 3., 3., 2., 1.] - } + import cdms2,sys,vcs,sys,os + src = sys.argv[1] + pth = os.path.join(os.path.dirname(__file__),"..") + sys.path.append(pth) + import checkimage + x = vcs.init() + x.drawlogooff() // It is important to disable logo for testing + f = cdms2.open(vcs.prefix+"/sample_data/clt.nc") + s = f("clt",slice(0,1),squeeze=1) + b = x.createboxfill() + b.level_1 = .5 + b.level_2 = 14.5 + x.plot(s,b,bg = 1) - frame = DataFrame(data) - pivoted = frame.pivot(index='index', columns='columns', values='values') + fnm = "test_boxfill_lev1_lev2.png" - expected = DataFrame({ - 'One' : {'A' : 1., 'B' : 2., 'C' : 3.}, - 'Two' : {'A' : 1., 'B' : 2., 'C' : 3.} - }) + x.png(fnm) - assert_frame_equal(pivoted, expected) + ret = checkimage.check_result_image(fnm,src,checkimage.defaultThreshold) + sys.exit(ret) #### Running the test suite @@ -217,7 +219,7 @@ constructs: ctest -R test-name ctest -R regex* - + #### Running the performance test suite TODO @@ -297,7 +299,7 @@ GitHub. You can see the remote repositories : If you added the upstream repository as described above you will see something like : - origin git://github.com/UV-CDAT/uvcdat.git + origin git://github.com/UV-CDAT/uvcdat.git myuvcdat git@github.com:yourname/uvcdat.git (fetch) myuvcdat git@github.com:yourname/uvcdat.git (fetch) From 2eef582ed7621f1b948567231e827f997a59c0d2 Mon Sep 17 00:00:00 2001 From: Aashish Chaudhary Date: Sun, 7 Jun 2015 22:05:02 -0400 Subject: [PATCH 3/8] Rename for clarity --- DEVELOP.md => CONTRIBUTE.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename DEVELOP.md => CONTRIBUTE.md (100%) diff --git a/DEVELOP.md b/CONTRIBUTE.md similarity index 100% rename from DEVELOP.md rename to CONTRIBUTE.md From 9b4dea9d1d8ec21cd49f09d77bdf89db3bbbadc0 Mon Sep 17 00:00:00 2001 From: Aashish Chaudhary Date: Sun, 7 Jun 2015 22:24:37 -0400 Subject: [PATCH 4/8] Fixed minor mistakes --- CONTRIBUTE.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/CONTRIBUTE.md b/CONTRIBUTE.md index 8a640de980..ceaa757b10 100644 --- a/CONTRIBUTE.md +++ b/CONTRIBUTE.md @@ -120,9 +120,8 @@ command. ### Making changes Before making your code changes, it is often necessary to build the code -that was just checked out. There are two primary methods of doing this. - -The best way to develop *UV-CDAT* is to build using default settings: +that was just checked out. The best way to develop *UV-CDAT* is to build +using default settings: mkdir uvcdat-build cmake uvcdat-path-to-source From 10d67af7a73781636f42983375deff695de8b255 Mon Sep 17 00:00:00 2001 From: Aashish Chaudhary Date: Sat, 13 Jun 2015 12:34:45 -0400 Subject: [PATCH 5/8] Renamed to follow github guidelines --- CONTRIBUTE.md => CONTRIBUTING.md | 6 ------ 1 file changed, 6 deletions(-) rename CONTRIBUTE.md => CONTRIBUTING.md (99%) diff --git a/CONTRIBUTE.md b/CONTRIBUTING.md similarity index 99% rename from CONTRIBUTE.md rename to CONTRIBUTING.md index ceaa757b10..f432f95411 100644 --- a/CONTRIBUTE.md +++ b/CONTRIBUTING.md @@ -367,9 +367,3 @@ feature branch has not actually been merged. The branch will still exist on GitHub, so to delete it there do : git push origin --delete shiny-new-feature - - - - - - From 08bc2bb424dd2de4c9f9423f9cb209598d199438 Mon Sep 17 00:00:00 2001 From: Aashish Chaudhary Date: Sat, 13 Jun 2015 12:44:35 -0400 Subject: [PATCH 6/8] Added specifics about when someone should fork --- CONTRIBUTING.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index f432f95411..1d4e0aa6df 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -84,9 +84,10 @@ local repository and GitHub. ### Forking -You will need your own fork to work on the code. Go to the [UV-CDAT -project page](https://github.com/UV-CDAT/uvcdat) and hit the *fork* -button. You will want to clone your fork to your machine: : +You may want to fork UV-CDAT to work on the code if you have access to the repository, +then just create a branch there instead. If you don't then follow these guidelines +for forking UV-CDAT. Go to the [UV-CDAT project page](https://github.com/UV-CDAT/uvcdat) +and hit the *fork* button. You will want to clone your fork to your machine: git clone git://github.com/UV-CDAT/uvcdat.git UV-CDAT-yourname cd UV-CDAT-yourname From ebbcc8dd799c1cc5b99cbc73e0daac2013e3f3eb Mon Sep 17 00:00:00 2001 From: Aashish Chaudhary Date: Sat, 13 Jun 2015 15:05:47 -0400 Subject: [PATCH 7/8] Added reference to contributing from readme --- CONTRIBUTING.md | 24 ++++++++++++------------ README.md | 6 ++++++ 2 files changed, 18 insertions(+), 12 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 1d4e0aa6df..577c345637 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -87,7 +87,8 @@ local repository and GitHub. You may want to fork UV-CDAT to work on the code if you have access to the repository, then just create a branch there instead. If you don't then follow these guidelines for forking UV-CDAT. Go to the [UV-CDAT project page](https://github.com/UV-CDAT/uvcdat) -and hit the *fork* button. You will want to clone your fork to your machine: +and hit the *fork* button. You will want to clone your fork to your machine: (HTTPS +or SSH is preferred to git:// for security reasons). git clone git://github.com/UV-CDAT/uvcdat.git UV-CDAT-yourname cd UV-CDAT-yourname @@ -96,10 +97,9 @@ and hit the *fork* button. You will want to clone your fork to your machine: This creates the directory UV-CDAT-yourname and connects your repository to the upstream (main project) *UV-CDAT* repository. -You will also need to hook up Travis-CI to your GitHub repository so the -suite is automatically run when a Pull Request is submitted. -Instructions are -[here](http://about.travis-ci.org/docs/user/getting-started/). +You will also need to hook up Travis-CI to your GitHub (if you have forked) +repository so the suite is automatically run when a Pull Request is submitted. +Instructions are [here](http://about.travis-ci.org/docs/user/getting-started/). ### Creating a Branch @@ -128,15 +128,13 @@ using default settings: cmake uvcdat-path-to-source make -jN - If you startup the Python interpreter in the *UV-CDAT* source - directory you will call the built C extensions - Contributing to the documentation --------------------------------- If you're not the developer type, contributing to the documentation is still of huge value. You don't even have to be an expert on *UV-CDAT* to -do so! Something as simple as +do so! Something as simple as pointing missing information or broken links +will be of great value. Contributing to the code base ----------------------------- @@ -266,13 +264,15 @@ The following defines how a commit message should be structured. Please reference the relevant GitHub issues in your commit message using GH1234 or \#1234. Either style is fine, but the former is generally preferred: -> - a subject line with \< 80 chars. +> - a subject line with \< 80 chars (50-char subject, 72-char rest). > - One blank line. -> - Optionally, a commit message body. +> - Optionally, a commit message body (72-char). Now you can commit your changes in your local repository: - git commit -m + git commit -a +or + git commit -a -m "Message..Here" If you have multiple commits, it is common to want to combine them into one commit, often referred to as "squashing" or "rebasing". This is a diff --git a/README.md b/README.md index d812db7b7f..77d98ea886 100644 --- a/README.md +++ b/README.md @@ -9,3 +9,9 @@ uvcdat Developed by partnering with ESGF and the community to create a larger problem-solving environment, UV-CDAT is an open source, easy-to-use application that links together disparate software subsystems and packages to form an integrated environment for analysis and visualization. This project seeks to advance climate science by fulfilling computational and diagnostic/visualization capabilities needed for DOE's climate research. Led by Lawrence Livermore National Laboratory (LLNL), the consortium consists of four DOE laboratories (Los Alamos, Lawrence Berkeley, LLNL, and Oak Ridge), two universities (University of Utah and the Polytechnic Institute of New York University), NASA, and two private companies (Kitware and tech-X) that will develop reusable software and workflow analysis and visualization applications for large-scale DOE climate modeling and measurements archives. The UV-CDAT concept is simple and flexible enough to interchange parts to expand for future DOE activities. + +Developing and Contributing +------ +We'd love to get contributions from you! Please take a look at the +[Contribution Documents](CONTRIBUTING.md) to see how to get your changes merged +in. \ No newline at end of file From 2378fccc2985d971ab3e344676c8dede2b2dea32 Mon Sep 17 00:00:00 2001 From: Aashish Chaudhary Date: Thu, 9 Jul 2015 18:00:45 -0400 Subject: [PATCH 8/8] Addressed review comments --- CONTRIBUTING.md | 25 +++++++------------------ 1 file changed, 7 insertions(+), 18 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 577c345637..44e1d2fd11 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -13,7 +13,7 @@ tab](https://github.com/UV-CDAT/uvcdat/issues) and start looking through interesting issues. Feel free to ask questions on [mailing -list](uvcdat-users@llnl.gov) +list](uvcdat-users@llnl.gov) or [askbot](http://askbot-uvcdat.llnl.gov/questions) Bug Reports/Enhancement Requests -------------------------------- @@ -140,13 +140,8 @@ Contributing to the code base ----------------------------- ### Code Standards -*UV-CDAT* uses the [PEP8](http://www.python.org/dev/peps/pep-0008/) -standard. There are several tools to ensure you abide by this standard. - -Alternatively, use [flake8](http://pypi.python.org/pypi/flake8) tool for -checking the style of your code. Additional standards are outlined on -the [code style wiki -page](LINK HERE). +*UV-CDAT* uses [flake8](http://pypi.python.org/pypi/flake8) tool for +checking the style of your code. Please try to maintain backward-compatibility. *UV-CDAT* has lots of users with lots of existing code, so don't break it if at all possible. @@ -175,6 +170,8 @@ All tests should go into the *tests* subdirectory of the specific package. There are probably many examples already there and looking to these for inspiration is suggested. +#### Regression testing + The `testing.checkimage.py` module has special `check_result_image` function that make it easier to check whether plot produced after data extraction and transformation are equivalent to baseline. For an example see below: @@ -202,7 +199,7 @@ transformation are equivalent to baseline. For an example see below: #### Running the test suite -The tests can then be run directly inside your build tree by typing:: +The tests can then be run directly inside your build tree (directory) by typing:: ctest @@ -218,14 +215,6 @@ constructs: ctest -R test-name ctest -R regex* -#### Running the performance test suite - -TODO - -### Documenting your code - -TODO - Contributing your changes to *UV-CDAT* ------------------------------------- @@ -348,7 +337,7 @@ automatically updated. Pushing them to GitHub again is done by: This will automatically update your Pull Request with the latest code and restart the Travis-CI tests. -### Delete your merged branch (optional) +### Delete your merged branch from your fork (optional) Once your feature branch is accepted into upstream, you'll probably want to get rid of the branch. First, merge upstream master into your branch