specify 0.10.2 → 1.0.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
-SHA1:
-  metadata.gz: 87785f51fa0d7d5c529b7856afdeec58b5fb33f2
-  data.tar.gz: 76ec7120adbd2fb1f2e0976756f9f9a7990bb825
+SHA256:
+  metadata.gz: d8d284ca6600d067bcd67451cb6af8abef30831d25d1b2d5a1e9b4fe4619f127
+  data.tar.gz: 20b23de09742a461528a04df263b68ff11ddd0efcda66231242caa4f2efe71e6
 SHA512:
-  metadata.gz: 8d0045e2c22929aff89fb8e34a707a4bc5dc2c62e5a9cee5f5eed38d04e50f382f86e22e3e90c8ec0241047f81e053d215d9a344668bba0535fe0d99bdf04ce9
-  data.tar.gz: 0904c0da9c04efc6cf88d3b056a1f58fdf8859f20cf1c41ed3b2d6f1151c5f005c27598076bc543e838c4222b19d0906024babf552f0a916f2a254f67ac808f5
+  metadata.gz: e74dad48ac6b8216a2d47f038fa65a9769c46e001e921be9f02982f0e1bd5f9903b4b20dd073cb39f3c30698d87b792eed7609b5ddff778af2ee8308d18d9917
+  data.tar.gz: c5ff56f667afa59729bfc8a4c802794d0266233c4c72ec2fff8c8d6e93a4ade47beb3c37d59227479375e1130f534464dc42c2a3e66a5c95cda0c1ed51a73315

data/.gitignore

@@ -1,29 +1,49 @@
-*.gem
-*.rbc
-.idea
-.bundle
-.config
-.yardoc
-Gemfile.lock
-InstalledFiles
-_yardoc
-coverage
-doc/
-lib/bundler/man
-pkg
-rdoc
-spec/reports
-spec/examples.txt
-test/tmp
-test/version_tmp
-tmp
-*.bundle
-*.so
-*.o
-*.a
-._*
-mkmf.log
+# Ruby Generated
+
+/Gemfile.lock
+/.bundle/
+/.yardoc
+/_yardoc/
+/coverage/
+/doc/
+/pkg/
+/spec/reports/
+/spec/coverage/
+/tmp/
+
+# Generated Reports
+reports/
+
+# Rspec Failure Tracking
+
+.rspec_status
+
+# IDE Files
+
+.idea/
+*.iml
+*.iws
+*.ipr
+.vscode/
+.settings/
+.metadata
+.classpath
+.loadpath
+.buildpath
+.project
+
+# OS Files
+
 .DS_Store
 .DS_Store?
+._*
+.Spotlight-V100
 .Trashes
-.thumbs.db
+ehthumbs.db
+Thumbs.db
+$RECYCLE.BIN/
+Desktop.ini
+*.tmp
+*.bak
+*.swp
+*~.nib

data/.hound.yml

@@ -1,95 +1,78 @@
 AllCops:
   Exclude:
     - specify.gemspec
-    - test/*.rb
     - spec/**/*
 
-# missing top-level module documentation comment
+# Removing need for frozen string literal comment.
+Style/FrozenStringLiteralComment:
+  Enabled: false
+
+# Removing the preference for string single quotes.
+Style/StringLiterals:
+  Enabled: false
+
+# Missing top-level module documentation comment.
 Style/Documentation:
   Enabled: false
 
-# prefer reduce over inject
+# Prefer reduce over inject.
 Style/CollectionMethods:
   PreferredMethods:
     reduce: 'inject'
 
-# use each_with_object instead of inject
+# Use each_with_object instead of inject.
 Style/EachWithObject:
   Enabled: false
 
-# removing the preference for string single quotes
-Style/StringLiterals:
-  Enabled: false
-
-# prefer fail over raise
+# Prefer fail over raise.
 Style/SignalException:
   Enabled: false
 
-Style/TrailingComma:
-  EnforcedStyleForMultiline: comma
-
-# this never works for validations
-Style/AlignHash:
+# This never works for validations.
+Layout/AlignHash:
   EnforcedLastArgumentHashStyle: ignore_implicit
 
-# align multi-line params with previous line
-Style/AlignParameters:
+# Align multi-line params with previous line.
+Layout/AlignParameters:
   EnforcedStyle: with_fixed_indentation
 
-# indent `when` clause one step from `case`
-Style/CaseIndentation:
+# Indent `when` clause one step from `case`.
+Layout/CaseIndentation:
   IndentOneStep: true
 
-# don't force crappy var names for reduce/inject loops
+# Don't force bad var names for reduce/inject loops.
 Style/SingleLineBlockParams:
   Enabled: false
 
-# for method chains, keep the dot with the method name
-Style/DotPosition:
+# For method chains, keep the dot with the method name.
+Layout/DotPosition:
   EnforcedStyle: leading
 
-Style/AccessorMethodName:
-  Enabled: false
-
-Style/PredicateName:
-  Enabled: false
-
-Style/MethodName:
-  Enabled: false
-
-Style/Alias:
-  Enabled: false
-
-Style/Next:
-  Enabled: false
-
-# stop nesting so hard
+# Stop nesting so hard.
 Metrics/BlockNesting:
   Max: 2
 
-# short methods
+# Encourage short methods.
 Metrics/MethodLength:
-  Max: 25
+  Max: 15
 
-Metrics/LineLength:
-  Enabled: false
-  #Max: 115
+# Encourage short (as possible) modules.
+Metrics/ModuleLength:
+  Max: 100
 
-# fewer parameters
+# Encourage fewer parameters.
 Metrics/ParameterLists:
-  Max: 5
+  Max: 4
 
-Metrics/AbcSize:
+# Remove execute permissions check.
+Lint/ScriptPermission:
   Enabled: false
 
-Metrics/ModuleLength:
-  Max: 130
-
-Metrics/CyclomaticComplexity:
-  Max: 12
+# Specify Additions
 
-Metrics/PerceivedComplexity:
-  Max: 12
-
-Lint/RescueException:
-  Enabled: false
+# This checks assignments, branches and coverage. During development,
+# adding to the output of RSpec in a way that reads cleanly as code
+# means being a little only slightly more forgiving for this metric.
+# The default value is 15.
+Metrics/AbcSize:
+  Max: 17

data/.rspec

@@ -0,0 +1,3 @@
+--format RSpec::Specify::Formatter
+--color
+--require spec_helper

data/.rubocop.yml

@@ -1,2 +1,6 @@
+inherit_mode:
+  merge:
+    - Exclude
+
 inherit_from:
   - .hound.yml

data/.travis.yml

@@ -1,18 +1,14 @@
-language: ruby
-
+---
 sudo: false
+language: ruby
+cache: bundler
 
 rvm:
-  - 2.0.0
-  - 2.1
-  - 2.2
+  - 2.5.1
+
+before_install:
+  - gem install bundler
 
 branches:
   only:
     - master
-
-notifications:
-  recipients:
-    - jeffnyman@gmail.com
-
-before_install: gem install bundler -v 1.10.6

data/CODE_OF_CONDUCT.md

@@ -1,13 +1,74 @@
-# Contributor Code of Conduct
+# Contributor Covenant Code of Conduct
 
-As contributors and maintainers of this project, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.
+## Our Pledge
 
-We are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, or religion.
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of experience,
+nationality, personal appearance, race, religion, or sexual identity and
+orientation.
 
-Examples of unacceptable behavior by participants include the use of sexual language or imagery, derogatory comments or personal attacks, trolling, public or private harassment, insults, or other unprofessional conduct.
+## Our Standards
 
-Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct. Project maintainers who do not follow the Code of Conduct may be removed from the project team.
+Examples of behavior that contributes to creating a positive environment
+include:
 
-Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by opening an issue or contacting one or more of the project maintainers.
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
 
-This Code of Conduct is adapted from the [Contributor Covenant](http://contributor-covenant.org), version 1.0.0, available at [http://contributor-covenant.org/version/1/0/0/](http://contributor-covenant.org/version/1/0/0/)
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at jeff.nyman@yello.co. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

data/Gemfile

@@ -1,3 +1,7 @@
-source 'https://rubygems.org'
+source "https://rubygems.org"
+
+gem "coveralls", require: false
+
+git_source(:github) { |repo_name| "https://github.com/#{repo_name}" }
 
 gemspec

data/LICENSE.md

@@ -0,0 +1,21 @@
+The MIT License (MIT)
+
+Copyright (c) 2018 Jeff Nyman
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+THE SOFTWARE.

data/README.md

@@ -1,25 +1,22 @@
 # Specify
 
-[![Build Status](https://travis-ci.org/jnyman/specify.svg)](https://travis-ci.org/jnyman/specify)
+> **The height of sophistication is simplicity.**<br>
+> &nbsp;&nbsp;&nbsp;&nbsp;*Clare Boothe Brokaw*
 
-[![Coverage Status](https://img.shields.io/coveralls/jnyman/specify.svg)](https://coveralls.io/r/jnyman/specify?branch=master)
 [![Gem Version](https://badge.fury.io/rb/specify.svg)](http://badge.fury.io/rb/specify)
-[![Dependency Status](https://gemnasium.com/jnyman/specify.svg)](https://gemnasium.com/jnyman/specify)
-[![Code Climate](https://codeclimate.com/github/jnyman/specify/badges/gpa.svg)](https://codeclimate.com/github/jnyman/specify)
+[![Build Status](https://travis-ci.org/jeffnyman/specify.svg)](https://travis-ci.org/jeffnyman/specify)
+[![License](http://img.shields.io/badge/license-MIT-blue.svg)](https://github.com/jeffnyman/specify/blob/master/LICENSE.md)
+[![Maintainability](https://api.codeclimate.com/v1/badges/a42684de1702ed5a9333/maintainability)](https://codeclimate.com/github/jeffnyman/specify/maintainability)
 
-[![Gitter chat](https://badges.gitter.im/jnyman/specify.png)](https://gitter.im/jnyman/specify)
-[![endorse](https://api.coderwall.com/jnyman/endorsecount.png)](https://coderwall.com/jnyman)
+---
 
-> _"Simplicity is the ultimate sophistication."_
-> -- <cite>Leonardo da Vinci</cite>
+Specify is a tool for leveraging RSpec to create an expressive DSL for test and data conditions. Specify will also provide test result reporting that recognizes the DSL.
 
-Specify is a test solution development tool that acts as a BDD-style micro-framework.
-
-Specify provides a very thin wrapper around RSpec that provides a Gherkin-style syntax for use with test examples.
+Specify provides an internal DSL, similar to the [RSpec Story Runner](https://github.com/dchelimsky/rspec-stories). This was the predecessor of the [Cucumber](http://cukes.info/) external DSL provided by [Gherkin](http://cukes.info/gherkin.html).
 
 ## Installation
 
-To get the latest stable release, add this line to your application's Gemfile:
+Add this line to your application's Gemfile:
 
 ```ruby
 gem 'specify'
@@ -28,45 +25,173 @@ gem 'specify'
 To get the latest code:
 
 ```ruby
-gem 'specify', git: https://github.com/jnyman/specify
+gem 'specify', git: 'https://github.com/jeffnyman/specify'
 ```
 
 After doing one of the above, execute the following command:
 
-    $ bundle
+```
+$ bundle
+```
 
 You can also install Specify just as you would any other gem:
 
-    $ gem install specify
+```
+$ gem install specify
+```
 
 ## Usage
 
-To use Specify you simply have to require it within your `spec_helper` file:
+To use Specify you simply have to require it within your `spec_helper.rb` file:
 
 ```ruby
 require 'specify'
 ```
 
-Then you simply run your `rspec` command as normal against your test suite.
+Because Specify uses a custom formatter, you should have an `.rspec` file with the following line in it:
+
+```ruby
+--format RSpec::Specify::Formatter
+```
+
+Then you simply run your `rspec` command as normal against your test suite. Where the Specify formatter comes into play is in how you can construct your test specifications. You can use RSpec constructs within Specify constructs. Here is an example:
+
+```ruby
+Feature 'Bank Accounts' do
+  let(:valid_account_number) { '1234567890' }
+  subject { Account.new(valid_account_number) }
+
+  Scenario 'starting a new account' do
+    test 'will have a starting balance of 0' do
+      expect(subject.balance).to eq(0)
+    end
+
+    it 'will not allow an invalid account name' do
+      expect { Account.new('thx1138') }.to raise_error(InvalidAccountNumberError)
+    end
+  end
+end
+```
+
+You can see that within the Specify-provided `Feature` construct I have the standard `let` and `subject` elements. Within the Specify-provided `Scenario` you can see I use a Specify-provide method (`test`) and an RSpec-provided method (`it`).
+
+Modern development practices put an emphasis on communication. Much of this communication is done via the mechanisms of tests. These tests ideally act as readable specifications that communicate the intent of a test. Equally ideally, however, these tests do not hide the code that executes them behind too many layers of abstractions.
+
+Tools in the xSpec family, of which RSpec is a part, do a good job of keeping code as a first-class citizen. This is contrasted with tools in the xBehave family, of which Cucumber is a part, where you have various abstractions like feature files sitting in front of code. Beyond that you also often have an intermediary layer, like the step definition files of Cucumber, that add one more layer of maintenance.
+
+Beyond even that, such xBehave tools often do limit you to the expressions available via a structuring syntax, such as with the Gherkin API, that is outside of the code.
+
+Specify lets you write as much logic beside your specifications as you want by leveraging the RSpec ecosystem with the addition of a Gherkin-like syntax as well as additions to that syntax. Perhaps worth noting is that Specify has no dependence on Gherkin.
+
+The [unit tests](https://github.com/jeffnyman/specify/tree/master/spec) will give you some idea of how Specify allows the structuring of test specifications.
+
+### The Specify API
+
+In RSpec, `describe` creates an example group and `it` creates a single example. You can use `context` as an alias for `describe` and you can use `example` and `specify` as aliases for `it`. Specify does a couple of things in the context of the API that RSpec provides.
+
+Specify adds a few new example groups: `Feature` and `Story`. These are considered top-level example groups. Because they are top-level, they are mutually exlcusive so you can't have one nested within the other.
+
+Specify also provides another set of example groups: `Ability`, `Component`, `Workflow`, and `Service`. These can be nested within one another and can be nested within the top-level example groups.
+
+Specify provides some constructs that map to RSpec hooks as well: `Background` and `Setup` (both of which act like an RSpec `before`) along with `Teardown` and `Cleanup` (both of which act like an RSpec `after`).
+
+As a very simple example, consider this:
+
+```ruby
+Feature 'The Nature of Truth' do
+  Ability 'logic tests can be applied' do
+    Scenario 'true is not false' do
+      Then 'true is almost certainly not false' do
+        expect(true).to_not be false
+      end
+    end
+
+    Scenario 'true is true' do
+      Then 'true is pretty definitely true' do
+        expect(true).to be true
+      end
+    end
+  end
+end
+```
+
+Gherkin structures allow you to use the word "Ability" as an alias for "Feature". However Specify takes the viewpoint that a feature could be speaking to a high-level viewpoint, within which there are multiple abilities. Thus you can use both descriptors simultaneously, one nested within the other, which would not be possible with Gherkin. You can also see here that multiple Scenario blocks can be included within a Feature or Ability just as they would in Gherkin.
+
+You might know that RSpec allows you to define your own names for its constructs already. For example, I could do something like this:
+
+```ruby
+RSpec.configure do |rspec|
+  rspec.alias_example_group_to :scenario
+  rspec.alias_example_to :then
+end
+```
+
+So why wouldn't you just do that instead of using something like Specify? The answer lies in realizing that the `Scenario` implementation provided by Specify is not just acting as an alias for `context`. Rather, Specify hooks into RSpec to change the execution. This is done by extending RSpec to support step groups.
+
+### Specify Augments RSpec
 
-## Why Specify?
+RSpec is predicated upon unit testing or, at most, integration testing. Thus RSpec focuses on providing a runner that works for edge-to-edge tests. As such, RSpec's mode of action is that all examples should be completely independent. Consider this:
 
-Specify provides an internal DSL, similar to the [RSpec Story Runner](https://github.com/dchelimsky/rspec-stories), which was the predecessor of the [Cucumber](http://cukes.info/) external DSL provided by [Gherkin](http://cukes.info/gherkin.html).
+```ruby
+context 'Simple Scenario' do
+  it 'sets up some context' do
+  end
+
+  it 'takes some action'
+  end
+
+  it 'observes some result' do
+  end
+end
+```
 
-Behavior Driven Development (or even just good Test Driven Development) practices put emphasis on communication. Tools like Cucumber focus on allowing communication via a test description language, structured by Gherkin keywords. However, while the ideas of Gherkin are nice, tools like Cucumber abstract away the nuts and bolts of your tests.
+Here each it block is a step but also is one independent test. The conditions for passing or failing must be within each step. Contrast this with a Cucumber feature scenario:
+
+```
+Scenario: 'Simple Scenario'
+  Given some context
+  When  some action
+  Then  some result
+```
 
-Abstraction can be a good thing but Cucumber gives you no choice in the matter. It hides code blocks behind a "call by regular expression" invocation mechanism instead of making those code blocks readily available in the acceptance test description.
+Here the `Scenario` block has three steps but they are not independent. They have to work together to be considered a passing or failing test.
 
-Specify lets you write as much logic beside your specifications as you want by leveraging the RSpec ecosystem with the addition of a Gherkin-like syntax.
+So, for end-to-end purposes, this means if you want to use RSpec you have to write a sequence of examples, each of which repeats the behavior of all previous examples. Another alternative is that you could write one single large example that performs the entire set of actions. The problem in that case is that there is no independent reporting of each step. Or you could try to rely on a clever use of `before` and `after` calls. The problem there is that the `before` and `after` logic may differ significantly between tests. This is why tools like Cucumber end up being used.
 
-The [wiki](https://github.com/jnyman/specify/wiki) contains more information about Specify.
+So that's one of the goals of Specify: provide just the good parts of Cucumber and skip all the questionable parts.
+
+At minimum this means the ability to chain examples into a series of steps that run in sequence and which stop when a step fails. This allows you to assemble a series of tests that should all pass, but where complete isolation of those tests is not sensible. Given how Specify augments RSpec, this allows RSpec to be less unit and more integration and certainly more end-to-end.
+
+Key to this is the ability to share state between example steps.
+
+To that end, within the idea of an example group, Specify provides some constructs that are marked with metadata of "has_steps": `Scenario`, `Behavior`, and `Condition`. You can use non-capitalized variations of these as well. These are considered step groups. These cannot be nested within one another.
+
+You can also use the following: `Steps`, `Rules`, `Tests`, `Facts` (along with non-capitalized variants). These are just meant to accommodate various ways of expressing tests but they also show you how Specify can be used to provide a grammar that is as expressive as you would like it to be.
+
+Specify allows the normal RSpec `it`, `example`, and `specify` example keywords to be used within these step groups. However, Specify also adds a few other example keywords based on the above constructs: `step`, `rule`, `test`, and `fact`. Specify also provides the Gherkin style keywords as examples: `Given`, `When`, `Then`, `And`, and `But`.
+
+RSpec provides multiple ways to create and use shared example groups. These come in pairs, with one method for defining a shared group and another for using it. So, in RSpec, `shared_context` and `include_context` are for reusing common setup and helper logic whereas `shared_examples` and `include_examples` are for reusing examples. Specify hooks into this general mechanism and provides `shared_steps` and `include_steps`. These shared steps go into RSpec's "world," which is an internal container that is used for holding global non-configuration data.
+
+## Development
+
+After checking out the repo, run `bin/setup` to install dependencies. Then, run `bundle exec rake spec:all` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment.
+
+To experiment with the code, run `bin/console` for an interactive prompt. If you want to make changes and see how they work as a gem installed on your local machine, run `bundle exec rake install`.
+
+The default `rake` command will run all tests as well as a Rubocop analysis.
+
+If you have rights to deploy a new version, make sure to update the version number in `version.rb`, and then run `bundle exec rake release`. This will create a git tag for the version, push git commits and tags, and push the `.gem` file to [rubygems.org](https://rubygems.org).
 
 ## Contributing
 
-To work on Specify:
+Bug reports and pull requests are welcome on GitHub at [https://github.com/jeffnyman/specify](https://github.com/jeffnyman/specify). The testing ecosystem of Ruby is very large and this project is intended to be a welcoming arena for collaboration on yet another test-supporting tool. As such, contributors are very much welcome but are expected to adhere to the [Contributor Covenant](http://contributor-covenant.org) which is provided as a [code of conduct](https://github.com/jeffnyman/specify/blob/master/CODE_OF_CONDUCT.md).
+
+The Specify gems follows [semantic versioning](http://semver.org).
+
+To contribute to Specify:
 
 1. [Fork the project](http://gun.io/blog/how-to-github-fork-branch-and-pull-request/).
-2. Create a feature branch. (`git checkout -b my-new-feature`)
+2. Create your feature branch. (`git checkout -b my-new-feature`)
 3. Commit your changes. (`git commit -am 'new feature'`)
 4. Push the branch. (`git push origin my-new-feature`)
 5. Create a new [pull request](https://help.github.com/articles/using-pull-requests).
@@ -78,13 +203,14 @@ To work on Specify:
 ## License
 
 Specify is distributed under the [MIT](http://www.opensource.org/licenses/MIT) license.
-See the [LICENSE](https://github.com/jnyman/symbiont/blob/master/LICENSE.txt) file for details.
+See the [LICENSE](https://github.com/jeffnyman/specify/blob/master/LICENSE.md) file for details.
 
 ## Credits
 
-Specify has been inspired by the following projects:
+Specify has been inspired by the following projects. Each provided me with ideas for what to do and, in some cases, for what not to do. All were invaluable as I better considered how to leverage RSpec's functionality.
 
 * [maniok_bdd](https://github.com/21croissants/maniok_bdd)
 * [rspec-gherkin](https://github.com/sheerun/rspec-gherkin)
 * [rspec example steps](https://github.com/railsware/rspec-example_steps)
 * [XSpec](https://github.com/xaviershay/xspec)
+* [Mouse Melon](https://github.com/wojtha/mouse_melon)