Developer Working Group 2: Code Submission Guidelines
Session Leader(s): Chris Barnett, Steve McDonald
Background & Agenda:
In order to work together effectively and produce a maintainable code base, we must make some decisions to establish the conventions and practices that we will use.
Areas for discussion:
1. coding style and practice for JavaScript and Java
2. practices and conventions for GitHub code submission
Below are links to Google docs providing some information on these topics. The documents are not meant as proposed drafts, but merely as springboards for discussion. Feel free to add comments and ideas.
The goal of the session is to provide a skeleton for a draft style guide by identifying areas of common agreement. From there we can work towards resolving areas of disagreement.
If some areas require more exploration, additional action items may emerge.
https://docs.google.com/document/d/1CYFtxvCk4_46-vYo9Tm6XCfOETExziGu-vfTgDLCArU/edit?usp=sharing
https://docs.google.com/document/d/1SZhIDXKA-IXV4uxSG1IqhXu0KpQ7NZ-y5sxW3SLTVqU/edit?usp=sharing
https://docs.google.com/document/d/1gN77H8egGDDrQ1sQAi9uo8RhX_rKi046YTaSzHbDm-M/edit?usp=sharing
Session notes:
Bess: Did this break anything, perhaps using unit test
Chris how do we get to unit tests
Steve: end to end tests too
Bess: experience on transitioning to multi-institution
Blacklight at UVa, unit test required for Stanford adoption
testing enables collaboration
all new code contributions require test coverage
provide example of good tests
used RSpec, Hudson/Travis
test driven development tends to improve code quality/refactor since functions are designed to be testable
Chris: rules enforces better development practices
Darrin: javascript testing
Mike: problematic, given scale of our JS, we should try something
Jasmine, but there are lots of frameworks
how do you want to run tests: command line/Node.js or in browser
Travis include node.js or phantom.js
Functional testing is useful but unit testing tends to provide more actionable results
adopted:
Mike will write up some JavaScript unit testing frameworks
adopted:
Java: everybody like JUnit
adopted:
use Travis, it connects well with GitHub and is free
Bess: first, check out, build and run tests, then change code and run tests, create pull request. CI/Travis runs to double check
?: It makes it so much easier to add code because test
Bess: need recommendataion for unit testing
Mike : Manning book JUnit in Action, http://www.manning.com/tahchiev/
GitHub policy
Mike: Simple branching is better
Master is latest stable code
Releases are tagged
Lots of forking
Mike: consider a master branch, a release branch that gets merged in
Releases are tags on the master branch
Maintenance branches are generated as needed
- The focus is on future development, not supporting old releases
- It isn’t merged back into master,
- Not a high priority
Bess: what is upgrade process
especially when local customization is significant
Darren: a lot of the customization is in config files
Action items:
new code requires test code
start after the 2.0 commit?
everyone to peruse: Manning book JUnit in Action, http://www.manning.com/tahchiev/
use Travis, it connects well with GitHub and is free
Mike will write up some JavaScript unit testing frameworks