new readme, tests

.learn

@@ -3,4 +3,4 @@ tags:
   - cli
 languages:
   - ruby
-resources: 0
+resources: 0

Gemfile.lock

@@ -0,0 +1,34 @@
+GEM
+  remote: https://rubygems.org/
+  specs:
+    coderay (1.1.0)
+    diff-lcs (1.2.5)
+    method_source (0.8.2)
+    pry (0.10.1)
+      coderay (~> 1.1.0)
+      method_source (~> 0.8.1)
+      slop (~> 3.4)
+    rspec (3.3.0)
+      rspec-core (~> 3.3.0)
+      rspec-expectations (~> 3.3.0)
+      rspec-mocks (~> 3.3.0)
+    rspec-core (3.3.2)
+      rspec-support (~> 3.3.0)
+    rspec-expectations (3.3.1)
+      diff-lcs (>= 1.2.0, < 2.0)
+      rspec-support (~> 3.3.0)
+    rspec-mocks (3.3.2)
+      diff-lcs (>= 1.2.0, < 2.0)
+      rspec-support (~> 3.3.0)
+    rspec-support (3.3.0)
+    slop (3.6.0)
+
+PLATFORMS
+  ruby
+
+DEPENDENCIES
+  pry
+  rspec
+
+BUNDLED WITH
+   1.10.6

README.md

@@ -24,4 +24,62 @@
 
 8. Show them how to walk through the errors in the CLI spec.
 
-Joshua Wargames clip. https://www.youtube.com/watch?v=7R0mD3uWk5c
+Joshua Wargames clip. https://www.youtube.com/watch?v=7R0mD3uWk5c
+
+## Objectives
+
+1. Build a CLI (command line interface) application.
+2. Become familiar with the strcutre of a CLI application. 
+3. Get comfortable reading test output for a CLI application. 
+
+
+## Overview
+![http://readme-pics.s3.amazonaws.com/2001_A_Space_Odyssey_Style_B.jpg]()
+
+The year is 2001, humanity has discovered a mysterious object buried beneath the Lunar surface. Before Earth's most capable (and heroic) scientists can board the *Discovery One* and investigate, we must program the super-intelligent computer, HAL 9000. Luckily for us, however, most of HAL's functionality is already up and running. Our job is program HAL's greeting to the user. 
+
+Our program will: 
+
+1. Greet the user.
+2. Ask the user to input their name.
+3. Capture and store the user's input using the `#gets` method. 
+4. Use that captured input to puts out a string that greets the user by name, using string interpolation. 
+
+Check out the video below to see the final product in action: 
+
+
+Notice that the the program is run with `ruby bin/greet`––we are using ruby to run the code in the executable file that lives in our `bin` directory. Let's take a closer look at our project structure now. 
+
+## Project Structure
+
+**If you haven't done so already, fork and clone this lab down onto your computer**. 
+
+Check out the file structure below. 
+
+```
+bin
+   |–– greet
+lib 
+   |–– greeting.rb
+spec
+   |–– 01_greeting_spec.rb
+   |–– 02_cli_spec.rb
+   |–– spec_helper.rb
+...
+```  
+
+Let's take a moment to review: 
+
+### The `bin` Directory
+
+The `bin` directory holds our **exectuable** file. This file is responsible for running the program. It contains code that actually enacts the command line interaction––i.e. greeting the user, asking the user for input, storing that input and then acting on it. 
+
+### The `lib` Directory
+
+The `lib` directory is where we place the code that our program relies on to run. It is the meat of our CLI application. Our executable file *requires* the files in the `lib` directory and uses the code (for example, calling on any methods we might define) to to enact the CLI. 
+
+### The `spec` Directory
+
+This directory contains the tests for our program. We have tests for the code in the `lib` directory in `spec/01_greeting.rb` and tests for the CLI, i.e. the user interaction portion of our application, in `spec/02_cli_spec.rb`. We'll use the test output from running `learn` along with the guidelines below to get our program working. 
+
+

bin/greet

@@ -1,7 +1,4 @@
 #!/usr/bin/env ruby
-require_relative "../lib/greeting"
+require_relative "../lib/greeting.rb"
 
-puts "Hi! I'm HAL, what's your name?"
-
-user_name = gets.chomp
-greeting(user_name)
+# code your CLI here!

lib/greeting.rb

@@ -1,3 +1 @@
-def greeting(name)
-  puts "Hello #{name}. It's nice to meet you."
-end
+# code the #greeting method here!

spec/01_greeting_spec.rb

@@ -0,0 +1,19 @@
+require_relative "../lib/greeting.rb"
+
+describe './lib/greeting.rb' do
+  it 'defines a greeting method' do
+    expect(defined?(greeting)).to be_truthy
+  end
+
+  context '#greeting' do 
+    it 'takes in an argument of a persons name' do 
+      expect {greeting("Bobby")}.to_not raise_error
+    end
+
+    it 'greets the person whose name was passed in as an argument' do
+      allow($stdout).to receive(:puts)
+      output = capture_puts{ greeting("Sally") }
+      expect(output).to include("Hello Sally. It's nice to meet you.")
+    end
+  end
+end

spec/02_cli_spec.rb

@@ -0,0 +1,33 @@
+require_relative "../lib/greeting.rb"
+
+describe './bin/greet executing a CLI Application' do
+  it 'outputs a welcome message and asks the user for input' do
+    allow($stdout).to receive(:puts)
+    allow(self).to receive(:gets).and_return("Don")
+    expect($stdout).to receive(:puts).with("Hi! I'm HAL, what's your name?"), "Make sure bin/greet has code that can output 'Hi! I'm HAL, what's your name?' exactly."
+    run_file("./bin/greet")
+  end
+
+  it 'uses #gets.strip to capture the user input and set it equal to a variable called name' do 
+    allow($stdout).to receive(:puts)
+    allow(self).to receive(:gets).and_return("Don")
+    name = get_variable_from_file("./bin/greet", "name")
+    expect(name).to eq("Don")
+    run_file("./bin/greet")
+  end
+
+  it "calls on the #greeting method with an argument of the user's name" do 
+    allow($stdout).to receive(:puts)
+    allow(self).to receive(:gets).and_return("Don")
+    expect(self).to receive(:greeting).with("Don"), "Make sure the bin/greet file has code that calls the #greeting method with an argument of the user's name."
+    run_file("./bin/greet")
+  end
+
+  it "calls on the #greeting method with an argument of the user's name and returns the new greeting, interpolating the user's name" do 
+    allow($stdout).to receive(:puts)
+    allow(self).to receive(:gets).and_return("Don")
+    output = capture_puts{ run_file("./bin/greet") }
+    expect(output).to include("Hello Don. It's nice to meet you.")
+    run_file("./bin/greet")
+  end
+end

spec/spec_helper.rb

@@ -1,82 +1,5 @@
-require_relative "../lib/greeting_cli.rb"
-
-# This file was generated by the `rspec --init` command. Conventionally, all
-# specs live under a `spec` directory, which RSpec adds to the `$LOAD_PATH`.
-# The generated `.rspec` file contains `--require spec_helper` which will cause this
-# file to always be loaded, without a need to explicitly require it in any files.
-#
-# Given that it is always loaded, you are encouraged to keep this file as
-# light-weight as possible. Requiring heavyweight dependencies from this file
-# will add to the boot time of your test suite on EVERY test run, even for an
-# individual file that may not need all of that loaded. Instead, make a
-# separate helper file that requires this one and then use it only in the specs
-# that actually need it.
-#
-# The `.rspec` file also contains a few flags that are not defaults but that
-# users commonly want.
-#
-# See http://rubydoc.info/gems/rspec-core/RSpec/Core/Configuration
 RSpec.configure do |config|
-# The settings below are suggested to provide a good initial experience
-# with RSpec, but feel free to customize to your heart's content.
-=begin
-  # These two settings work together to allow you to limit a spec run
-  # to individual examples or groups you care about by tagging them with
-  # `:focus` metadata. When nothing is tagged with `:focus`, all examples
-  # get run.
-  config.filter_run :focus
-  config.run_all_when_everything_filtered = true
-
-  # Many RSpec users commonly either run the entire suite or an individual
-  # file, and it's useful to allow more verbose output when running an
-  # individual spec file.
-  if config.files_to_run.one?
-    # Use the documentation formatter for detailed output,
-    # unless a formatter has already been configured
-    # (e.g. via a command-line flag).
-    config.default_formatter = 'doc'
-  end
-
-  # Print the 10 slowest examples and example groups at the
-  # end of the spec run, to help surface which specs are running
-  # particularly slow.
-  config.profile_examples = 10
-
-  # Run specs in random order to surface order dependencies. If you find an
-  # order dependency and want to debug it, you can fix the order by providing
-  # the seed, which is printed after each run.
-  #     --seed 1234
-  config.order = :random
-
-  # Seed global randomization in this process using the `--seed` CLI option.
-  # Setting this allows you to use `--seed` to deterministically reproduce
-  # test failures related to randomization by passing the same `--seed` value
-  # as the one that triggered the failure.
-  Kernel.srand config.seed
-
-  # rspec-expectations config goes here. You can use an alternate
-  # assertion/expectation library such as wrong or the stdlib/minitest
-  # assertions if you prefer.
-  config.expect_with :rspec do |expectations|
-    # Enable only the newer, non-monkey-patching expect syntax.
-    # For more details, see:
-    #   - http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectation-syntax
-    expectations.syntax = :expect
-  end
-
-  # rspec-mocks config goes here. You can use an alternate test double
-  # library (such as bogus or mocha) by changing the `mock_with` option here.
-  config.mock_with :rspec do |mocks|
-    # Enable only the newer, non-monkey-patching expect syntax.
-    # For more details, see:
-    #   - http://teaisaweso.me/blog/2013/05/27/rspecs-new-message-expectation-syntax/
-    mocks.syntax = :expect
-
-    # Prevents you from mocking or stubbing a method that does not exist on
-    # a real object. This is generally recommended.
-    mocks.verify_partial_doubles = true
-  end
-=end
+  config.order = :default
 end
 
 def run_file(file)
@@ -103,4 +26,4 @@ def capture_puts
   ensure
     $stdout = old_stdout
   end
-end
+end