us
- bff's
- made some software
- "serial language enthusiasts"
what we're talking about
- version control with git
- automated testing with ruby
oh btw
if you have questions, tweet with hashtag #gitrubytalk
technology of teamwork
- one constant in our field is collaboration
- tech assisting us always improving
- methodologies too!
some common ones
- waterfall, spiral
- agile, extreme, scrum
tools augment processes
- how do you work?
- how can you work better?
- what's out there to help?
common tools
- OS, editor, ide
- docs, tests
- revision control
and yes, git!
essentials
- low level content tracker (SHA1/DAG/etc)
- distributed
- simplifies parallel development
- emphasis on pull, not push
commits
branches
- points where commits diverge
- can be merged with eachother
- exist on your machine or elsewhere
remotes
- like svn repos but awesomer
- friends instead of svn servers
- push to, pull from. bring in changes
distributed
- all changes are on your machine
- you're free to inspect and change
- no wifi? no problem
why git?
- augments many workflows, including individual
- supports various protocols, git-svn lets you interop
- alternatives: bzr, darcs, hg
a quick spin
tada!
takeaways
- git is worth looking into
- simple, powerful, extensible
- easy to get started, see github.com
testing your codez
- what it is
- what it do
- how it is
- when to use
what is testing?
"a particular process or method for trying or assessing"
popular processes
- F5
- Alt+Tab Up+Enter
- "Yo, try it again"
why this sucks
- gets old, fast
- explicit setup of state
- mix of "test" code and real code
- its not permanent
what's better?
- Test::Unit
why is it better?
- guides our design from the top down, rather than bottom up
- best docs money can buy
- permanent knowledge of functionality
testing strategy
- write some tests
- run your tests
- make them pass
how to test
anatomy of Test::Unit
- test case
- test methods
- assertions
- setup and teardown methods
a test case
- defines your general testing stragegy
- usually mapped to a single class
- encapsulates the desired behaviour of our class
test method
- runs a method in vacuum environment
- asserts an expected outcome
assetrions
common assertions
- assert(expression) (determines if expression is true)
- assert_equal("foobar", "foo" + "bar")
- assertinstanceof(String, "foobar")
how a test suite runs
- runs the "setup" method in the testcase
- runs a test method
- runs the "teardown" method in the testcase
- repeat for every test method
- repeat for every test case
good times to write a test case
- whenever you'd use the shell to try something out
- whenever a bug is found
- when designing an interface
- all the time (google for: TATFT)