README.md in test_spec-1.0.0 vs README.md in test_spec-1.1.0

- old
+ new

@@ -58,30 +58,30 @@ ```ruby --format RSpec::TestSpec::Formatter ``` -You can use RSpec constructs within Specify constructs although there are some things to be aware of. Here is an example: +You can use RSpec constructs within TestSpec constructs although there are some things to be aware of. 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 + 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 Feature construct I have let and subject elements. Within the Scenario you can see I use a Specify method (Test) and an RSpec method (it). +You can see that within the Feature construct I have let and subject elements. Within the Scenario you can see I use a TestSpec method (Test) and an RSpec method (it). ## Documentation TestSpec provides an internal DSL that allows you to use a Gherkin-like structural syntax within traditional RSpec test suites. @@ -180,9 +180,174 @@ ``` You can also see here that multiple **Scenario** blocks can be included within a Feature or Ability. This should give a rough idea of how TestSpec provides an internal DSL. + +### TestSpec API + +The [unit tests](https://github.com/jeffnyman/test_spec/tree/master/spec) will give you some idea of how TestSpec works. + +To use TestSpec as an RSpec overlay, you have **descriptive containers** with the following keywords: + +* Feature, Ability, Story, Component, Workflow + +These are defined in the [spec.rb](https://github.com/jeffnyman/test_spec/blob/master/lib/test_spec/spec.rb) file. + +You have **example group sequences** with the following keywords: + +* Scenario, Condition, Behavior +* Step, Test, Rule, Fact +* steps, tests, rules, facts + +These are defined in the [test_spec.rb](https://github.com/jeffnyman/test_spec/blob/master/lib/test_spec.rb) file. + +You have **example steps** with the following keywords: + +* (Gherkin steps) Given, When, Then, And, But +* (RSpec steps) it, specify, example +* (Specify steps) step, test, rule, fact + +These are defined in the [example_group.rb](https://github.com/jeffnyman/test_spec/blob/master/lib/test_spec/rspec/example_group.rb) file. + +The API is basically this: **Containers contain example groups that contain example steps.** Everything must essentially be nested in that order. This allows you to follow just about every xSpec or xBehave pattern out there. + +Some representative examples: + +```ruby +Feature 'some feature description' do + Scenario 'some test condition' do + Given 'some context' do + end + + When 'some action' do + end + + Then 'some observable' do + end + end +end +``` + +```ruby +Workflow 'some workflow description' do + Behavior 'some behavior description' do + example 'some test condition' do + end + + example 'some other test condition' do + end + end +end +``` + +```ruby +Component 'some component name' do + rules 'some high-level rules condition' do + rule 'some specific rule test condition' do + end + + rule 'some other specific rule test condition' do + end + end +end +``` + +A few notes on this. + +Example group sequences and example steps cannot be top level. Only descriptive containers can be the top level artifact in a test spec. Also, example steps cannot be directly under descriptive containers. For example, you can't do this: + +```ruby +Ability 'ability keyword' do + When 'when keyword' do + end +end +``` + +Here the `When` (an example step) is under a descriptive container (`Ability`). But it needs to be within an example group (such as `Scenario`). + +It's also worth noting that descriptive containers cannot be used inside example groups. For example, you can't do this: + +```ruby +Ability 'ability keyword' do + Scenario 'scenario keyword' do + Story 'story keyword' do + end + end +end +``` + +Here the `Story` (a descriptive container) is used under a example group (`Scenario`). Descriptive containers, however, are top-level constructs. They provide a grouping method for one or more example groups. + +You can nest descriptive containers if you feel that provides better understanding of your test spec. For example: + +```ruby +Feature 'feature keyword' do + Workflow 'workflow keyword' do + Component 'component #1' do + Scenario 'scenario' do + end + end + + Component 'component #2' do + Scenario 'scenario' do + end + end + end +end +``` + +Here notice that the containers `Feature`, `Workflow` and `Component` are used together to indicate a relationship about what is being tested. Each of the innermost containers then has some example groups (`Scenario` in this case) which can contain specific tests. + +## Design Rationale + +TestSpec is a micro-framework. + +A micro-framework provides a focused solution, which means it does one thing and one thing only, instead of trying to solve each and every problem. While doing that one thing it does well, the micro-framework should do it while being expressive and concise. Further, it should be able to serve as one component of your own custom modularized framework, allowing you to compose solutions. + +### Frameworks are Effective and Efficient + +I believe that test solution frameworks require effective functionality, an efficient user experience, and demonstrable business impact. This all has to be delivered, deployed, and supported quickly and cost-effectively. You want the equivalent of a lower total cost of ownership and a faster time-to-market for whatever you produce (such as test artifacts). + +### Frameworks are Comfortable + +Like a programming language, a framework needs to be something you're comfortable with -- something that reflects your personal style and mode of working. That's what TestSpec is for me. + +TestSpec allows me to continue working with a Gherkin-like structure but putting my test specs closer to the code. Just as in RSpec, everything is in one place: the Ruby file. The benefit here is that you don't have to change the text in two places -- feature files and step definition files -- every time you change something. Further, there are no more matchers to sync up with natural language. TestSpec uses plain Ruby helper methods coupled with various patterns. + +### Frameworks Provide + +A framework provides a few key aspects. + +A place for everything: Structure and convention drive a good framework. Everything should have a proper place within the system; this eliminates guesswork and increases productivity. + +A culture and aesthetic to help inform programming decisions: Rather than seeing the structure imposed by a framework as constraining, see it as liberating. A good framework encodes its opinions, gently guiding you. Often, difficult decisions are made for you by virtue of convention. The culture of the framework helps you make fewer menial decisions and helps you focus on what matters most. + +### Frameworks Have Qualities + +I believe a test framework with good qualities will ... + +* Encode opinions. +* Have an elegant, concise syntax. +* Have powerful metaprogramming features. +* Be well suited as a host language for creating DSLs. +* Allow for an open ecosystem. + +### TestSpec (Conceptually) Compared + +Even though their domains are different, consider TestSpec in light of Rails. Rails is more than a programming framework for creating web applications. It's also a framework for thinking about web applications. + +Rails ships not as a blank slate equally tolerant of every kind of expression. On the contrary, Rails trades that flexibility for the convenience of "what most people need most of the time to do most things." + +You could argue that Rails is a designer straightjacket. Yet this straightjacket sets you free from focusing on the things that just don't matter and focuses your attention on the stuff that does. To be able to accept that trade, you need to understand not just how to do something in Rails, but also why it's done like that. Only by understanding the why will you be able to consistently work with the framework instead of against it. + +It doesn't mean that you'll always have to agree with a certain choice, but you will need to agree to the overachieving principle of conventions. You have to learn to relax and let go of your attachment to personal idiosyncrasies when the productivity rewards are right. + +So it is with TestSpec. + +A framework goal is to solve 80% of the problems that occur in your testing domain, assuming that the remaining 20% are problems that are unique to the application's domain. This implies that 80% of the code in an application is infrastructure. So here instead of focusing on the details of knitting an application together, you get to focus on the 20% that really matters. + +The framework lets you start right away by encompassing a set of intelligent decisions about how your logic should work and alleviating the amount of low-level decision making you need to do up front. As a result, you can focus on the problems you're trying to solve and get the job done more quickly. ## 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.