learn-co-curriculum / cartoon-collections

Cartoon Collections

Cartoon Collections

Objectives

• Get familiar iterating through arrays with enumerator methods like .collect or .map, .find, and .include?.
• Build methods and control their return values.
• Practice control flow with if and else statements.

Instructions

There are four methods to complete in this lab:

1. roll_call_dwarves
2. summon_captain_planet
3. long_planeteer_calls
4. find_the_cheese

Method 1 — roll_call_dwarves

This method should accept an array of dwarf names, for instance:

["Doc", "Dopey", "Bashful", "Grumpy"]

It should then print out each name, in number order, using puts. The print-out should look like this:

1.  Doc
2.  Dopey
3.  Bashful
4.  Grumpy

Look into the each_with_index method.

Once the test for this method is passing, move on to the next method.

Method 2 — summon_captain_planet

This method should accept an array argument of planeteer calls that will look like this:

planeteer_calls = ["earth", "wind", "fire", "water", "heart"]

It should then capitalize each element and add an exclamation point at the end. The return value of this method should be an array, in this example:

summon_captain_planet(planeteer_calls)
# => ["Earth!", "Wind!", "Fire!", "Water!", "Heart!"]

The .map or .collect method might be appropriate for this task, take a look at it here and here.

Once the test for this method is passing, move on to the next method, long planeteer calls.

Method 3 — long_planeteer_calls

The long_planeteer_calls method should accept an array of calls. The method should tell us if any of the calls are longer than four characters. For example:

short_words = ["puff", "go", "two"]
long_planeteer_calls(short_words)
#=> false

assorted_words = ["two", "go", "industrious", "bop"]
long_planeteer_calls(assorted_words)
#=> true

Notice the return value of this method is either true or false, depending on the array it was given as an argument.

Checkout the Ruby docs on arrays for a hint.

Once the test for this method is passing, move on to the last method.

Method 4 — find_the_cheese

The find_the_cheese method should accept an array of strings. It should then look through these strings to find and return the first string that is a type of cheese. The types of cheese that appear are "cheddar", "gouda", and "camembert".

For example:

snacks = ["crackers", "gouda", "thyme"]
find_the_cheese(snacks)
#=> "gouda"

soup = ["tomato soup", "cheddar", "oyster crackers", "gouda"]
find_the_cheese(soup)
#=> "cheddar"

If, sadly, a list of ingredients does not include cheese, return nil:

ingredients = ["garlic", "rosemary", "bread"]
find_the_cheese(ingredients)
#=> nil

You can assume that all strings will be lowercase. Take a look at the .include method for a hint. This method asks you to return a string value instead of printing it so keep that in mind.

Resources

• The .each_with_index method
• The .map method
• The .include method

cartoon-collections's Issues

?

Need to change the test in long_planeteer_calls testing for a true return.

Changing the calls_long array to: calls_long = ["wind", "earth", "fire", "water", "heart"] should fix this:

Currently, this particular test may give false positives; I was in the middle of trying to correct a student's understanding of how looping worked, and how array and string lengths differed when she more or less stumbled into a passing implementation.

This is potentially pretty bad, given it can mean some students with conceptual misunderstandings may have those misunderstandings reinforced by tests like this.

This code, currently, passes:

def long_planeteer_calls(array)
   array.each do |str|
     if str.length > 4
       return true
     end
       return false
    end
  end

(As, of course, do other if/else variations).

Ensuring the first item in the array isn't > 4 chars should ensure solutions like this don't pass and serve to lead students down the wrong path and into potential trouble down the road.

Obviously it's not exactly far off from a solution that would work just fine (moving return false down one line so that it's outside of the loop), but I feel it's a pretty important basic concept to understand :)

I imagine this was overlooked due to .any? being the solution most people would think of.

each_with_index vs each.with_index

so.. I used each_with_index per the instructions, but it is not valid

however, each.with_index is valid

this is highly confusing

Mistake in .rspec file

describe "#long_planteer_calls" do
it "returns true if any calls are longer than 4 characters" do
long_planteer_calls = ["earth", "wind", "fire", "water", "heart"] --> variable is long_planteer_calls
expect(long_planteer_calls(long_planeteer_calls)).to eq(true) --> variable is long_planeteer_calls
end

Misspelled variable causes test to fail due to undefined variable no matter what.

Segment can be found in lines 41-45 of cartoon_collections_spec.rb

Typo in spec file

In the Cartoon_collections_spec.rb file there was a typo i believe the word plan(e)teer was spelled wrong: I fixed it like this: describe "#long_planteer_calls" do it "returns true if any calls are longer than 4 characters" do long_planeteer_calls = ["earth", "wind", "fire", "water", "heart"] expect(long_planeteer_calls(long_planeteer_calls)).to eq(true) end it "returns false if all calls are shorter than 4 characters" do short_planeteer_calls = ["wind", "fire"] expect(long_planeteer_calls(short_planeteer_calls)).to eq(false) end

SHouldn't have two of the same expect stuf fin one if block

cartoon-collections/spec/cartoon_collections_spec.rb

Lines 33 to 35 in 565cfb6

	veggies = %w(carrot cucumber pepper)
	result = summon_captain_planet(veggies)
	["Carrot!", "Cucumber!", "Pepper!"].each { |w| expect(result).to include w }

That is doing another test...yet it's in the same it block. Should be two it blocks. Technically, we shouldn't just test the same method with two different inputs, but this blocks the just making it work for one input problem

rspec test typo

it "returns false if all calls are shorter than 4 characters" do
calls_short = ["wind", "fire"]
expect(long_planeteer_calls(calls_short)).to eq(false)
end

This should read "returns false if all calls are 4 characters or less"

More separation of expects into their own it blocks

notice how each of these

cartoon-collections/spec/cartoon_collections_spec.rb

Lines 51 to 61 in 565cfb6

	cheddar_cheese = %w(banana cheddar sock)
	expect(find_the_cheese(cheddar_cheese)).to eq 'cheddar'
	no_cheese = %w(ham cellphone computer)
	expect(find_the_cheese(no_cheese)).to eq nil
	camembert_cheese = %w(owl blanket camembert)
	expect(find_the_cheese(camembert_cheese)).to eq 'camembert'
	gouda_cheese = %w(gouda cheddar camembert pontoons)
	expect(find_the_cheese(gouda_cheese)).to eq 'gouda'

is a logical separate thing? Make it actually a logical separate thing! many it blocks

Solved This Lab with Incorrect Logic For #long_planeteer_calls and #find_the_cheese

Hey guys. I got to pass this test passing with an incorrect logic so seems the rspec didn't meet all criteria. I realized it afterward and managed to go back to fix my code and solve it.

Just wanted to report on it. Here's the incorrect logic that passed it:

#logic is not correct and I passed.
 def long_planeteer_calls(arr)
  arr.find do |x|
  if x.length == 4
   return false
  else
   return true
  end
  end
end   

#incorrect logic and it passed.
def find_the_cheese(arr)
  # the array below is here to help
  cheese_types = ["cheddar", "gouda", "camembert"]
  counter = 0
  arr.find do |x|
  if x == cheese_types[counter]
  x
  else
  nil
end
end
end

lab says that it wasn't forked

lab says that it wasn't forked, however, i completed the lab, passed the tests and submitted pull request.

Naming convention should be fixed

It doesn't really make sense to have a name collision like this intentionally. Even though Ruby can typically navigate around it, it seems unnecessarily complicated for where/what it is.

it "returns true if any calls are longer than 4 characters" do 
  long_planeteer_calls = ["earth", "wind", "fire", "water", "heart"] 
  expect(long_planeteer_calls(long_planeteer_calls)).to eq(true) 
end 

Method also named: long_planeteer_calls

Should be an easy fix.
@aturkewi

We never cover the %w array creator, yet we use it in the tests

https://github.com/learn-co-curriculum/cartoon-collections/blob/master/spec/cartoon_collections_spec.rb#L22

Just use the regular array creator

Testing two distinct things in one if

Here

cartoon-collections/spec/cartoon_collections_spec.rb

Lines 44 to 45 in 565cfb6

	short_planeteer_calls = %w(wind fire)
	expect(long_planteer_calls(short_planeteer_calls)).to eq(false)

we are testing the true and the false case.

Those belong in two different tests. In general you only want one expect per it anyways

Wrong test suite

The test suite tests for things not part of the code given. (This is a lab where all the code is handed to us to input, but the test suite is testing for different things).

Here is the code given to us:
`def hello_t(array)
i = 0

while i < array.length
yield(array[i])
i = i + 1
end

array
end

hello_t(["Tim", "Tom", "Jim"]) do |name|
if name.start_with?("T")
puts "Hi, #{name}"
end
end`

And here is the test suite:
`require "spec_helper"

describe "#hello_t" do
let (:names) { ["Tim", "Tom", "Jim"] }
it "only passes names that start with 'T' to the block" do
expect{hello_t(names){|name| puts "Hi, #{name}" }}.to output("Hi, Tim\nHi, Tom\n").to_stdout
end

it "returns an array with only names that start with 'T'" do
expect(hello_t(names) {|name| puts "Hi, #{name}" }).to eq(["Tim", "Tom"])
end

it "is case insensitive" do
other_names = ["tim", "tom", "jim"]
expect{hello_t(other_names){|name| puts "Hi, #{name}" }}.to output("Hi, tim\nHi, tom\n").to_stdout
end
end`

What it's supposed to do is iterate through the array, puts 'Hi, Tim' and 'Hi, Tom', and return the original array. The test suite wants other things, and an updated array returned.

Pass the lab in visual studio code type lab submit request my username and password from github

ommitting changes...
It looks like you have no changes to commit. Will still try updating your submission...
Pushing changes to GitHub...
Username for 'https://github.com': Seems there was an error pushing to GitHub. Trying again...
Pushing changes to GitHub...
Username for 'https://github.com': Seems there was an error pushing to GitHub. Trying again...
Pushing changes to GitHub...
Username for 'https://github.com': Seems there was an error pushing to GitHub. Trying again...
Pushing changes to GitHub...
Username for 'https://githu

Specs for #long_planeteer_calls cause false pass

Insufficient solution causes spec to pass

The spec

describe "#long_planeteer_calls" do
    it "returns true if any calls are longer than 4 characters" do
      calls_long = ["axe", "earth", "wind", "fire", "water", "heart"]
      expect(long_planeteer_calls(calls_long)).to eq(true)
    end

    it "returns false if all calls are shorter than 4 characters" do
    calls_short = ["wind", "fire"]
    expect(long_planeteer_calls(calls_short)).to eq(false)
    end

  end

False positive "Solution"

Students' first intuition may lead them to experiment with .length without first turning to iteration. Below is one of the possible solutions a student may attempt:

def long_planeteer_calls(words)
  if words.length > 4
    true
  else
    false
  end
end

Or even simply:

def long_planeteer_calls(words)
  words.length > 4
end

Explanation

Calling the #length method on the argument array returns the length of the array. Unfortunately, the way the spec is written causes this to pass the specs, since the only example that is expecting true has six elements in the array, and the only example expecting false has only two elements in the array.

Proposed solution

Simply removing two words from the argument given in the first spec and adding three or more words of length <= 4 to the second spec will fix this error, eliminating the possibility that a student could be passing spec with an insufficient solution.

#Staff

clarify instructions

Readme instructions ask to "It should then capitalize each element and add an exclamation point at the end. " whereas the test specs expect only the first letter of each word to be capitalized ie. .capitalize instead of .upcase