17-01-2022

1037 words 6 minutes

Week 3

Test Driven Development

past 2 weeks alone, structured

this week is goal focused

workshops during the week

gather evidence and use reflection for goals and progress

Tracking your Learning doc?

Track your learning on Github?

Use OOP ( Classes and Methods )

Pair using the driver and navigator styles - at 1400 today

Usually working on a screen, whereas in the future we will share a workspace

Follow an effective debugging process

track against bud

I can test drive my code

Methodologically solve problems

Use my own initiative

Boris bikes challenge, 1400 - 1700 every day

More steps than necessary to cover

Accept that there is not enought time to finish this module - decide on a soft goal, maybe 1/2 way.

Look for progress, not mastery

Airport challenge on Friday - do your best

There will be feedback on the airport challenge

Go to the exercises on GitHub, read through them, and pull them if you think you can do them

Timebox everything, and try to do things practically

POODR with Sandi Metz

Beginning Week 3

Unit Testing

LO

  1. Define unit testing as the process of testing the smallest possible 'unit' of a programme
  2. Understand each of the "3 As" of a unit test
  3. Write some simple unit tests

Unit tests are code, that, surpsingly, tests code.

They provide evidence, and reassurance, that the code functions in the expected way. Like a chef would test their food by taste, a TDD Dev will test their code by writing tests.

Automated testing provides quality and some security, and efficiency. Automated testing can even backtest all prior code against an update, to check if anything is broken in an unexpected way.

Unit testing however, is about breaking down blocks of code (SRP guided) into similiar unit tests that, the unit tests themselves being SRP guided - designed almost as mirrors to the main programme itself.

Take the code below:

class BankAccount
  def initialize
    @balance = 0
  end

  def print_balance
    "£#{@balance}"
  end

  def deposit(money)
    @balance += money
  end
end

There is a class called BankAccount, with the instance variable @balance

BankAccount has a method called deposit, which takes an integer argument, and adds it to the @balance instance variable

write a unit test RSpec style, to cover this class.

the first thing we should do is write an assertion

an assertion describes what we want to test (we want to assert, perhaps, that x > y)

in the BankAccount scenario above, we want to test the deposit method.

describe BankAccount do
	it 'can deposit some money' do
		bank_account = BankAccount.new

		bank_account.deposit(10)

		expect(bank_account.print_balance).to eq("£10")
	end
end

the above unit test will print something like the below

#TODO

Library example

Let's take a look at another example - a Library class, with 4 methods.

class Library
  def initialize
    @books = [
      {title: 'POODR', author: 'Sandi Metz', subject: 'OOP'},
      {title: 'Learn Ruby The Hard Way', author: 'Zed Shaw', subject: 'Ruby'},
      {title: 'Eloquent JavaScript', author: 'Marijn Haverbeke', subject: 'JS'},
      {title: 'The Well Grounded Rubyist', author: 'Sandi Metz', subject: 'Ruby'},
    ]
  end

  def find_book(title)
    @books.find { |book| book[:title] == title }
  end

  def add_book(book)
    @books.push(book)
  end

  def remove_book(title)
    @books.delete_if { |book| book[:title] == title }
  end

  def all_books_by_subject(subject)
    @books.select { |book| book[:subject] == subject }
  end

  def list_books
    @books
  end
end

for a class such as this - what is the purpose of the test? should we think as the user - what is my expected output, given input x? should we think as the programmer - is the input received going to always be type 'String'?

In the above, look at the array of hashes, k, v where k == symbol and v == string. Remember this! It is clear to read and understand. How would you send this into SQL?
Perhaps a good test of legibility - could someone, who has never touched code, understand what's happening here? Like the 2 clause rule :smiley:

Arrange, Act, Assert

The apprenticeship provider suggests three distinct sections

  1. Arrange the preconditions required for the code to run. Create variables and assign the necessary objects.
RSpec has Hooks(run this ruby code at this time), Helpers(ruby methods), and Shared Objects(:let(obj) { Obj.new(paramx-x param-y) if obj exists in this test
  1. Act execute the code which needs to run in order that the assertion be made
  2. Assert that the action has had an effect, or returned a value.

what would my unit tests be for the Library class? 5 in total, one for each method?

  1. does find_book return a book?
Look into the ruby find method .find
returns the first ele for which returns a truthy value

  1. add_book - is a book incl (title, author, subject) added to @books array?

  2. remove_book - when called, and provided the book exists in @books, is it removed from the array?

look into the ruby method .delete_if
there are three delete methods for an array
1. delete - removes all items equal to param
2. delete_at - takes an index and deletes at the index (remember 0 indexing)
3. delete_if - deletes element self, where block evaluates to true
  1. all_books_by_subject - returns all items that are subject
ruby method .select
returns an array containg elements where block evaluated to true
  1. list_books - returns the @books array object

Exc 2

What must be done for the above code to run

an object-instance of the Library class must first be instantiated

then the instance methods will need to be called

the tests must insert the correct parameters, in keeping with the Library class where a book item is a k,v sym,str containing :title, :author, :subject

what code must be set up?

Exc 3

Write the unit tests

  1. Clone the repo
  2. run bundle
  3. write the RSpec tests, run from the terminal

Driver - Navigator Pairing

Factors

  1. How often are breaks? and break duration?
  2. How often will we switch between driver and navigator?
  3. Feedback - Most Important!!! Designate a Feedback Space! maybe have an hour - and ask for the feedback

One thing I did well One thing I could change and/or improve

Be kind - ASK

  • emotional check-in

  • session goal

  • Actionable

There will be multiple copies of the Boris Bikes

Different pair everyday

We are doing the Boris Bikes today!

Add new partner as collaborator

One person creates a repo on the Github

add the pair partner as a collaborator

collab writes - push and pull to the same repo

Pair Programming Sess.1

How did today go?

  • I think there were many good things, and things we could impove upon in the future:
  • I did also learn how to make tables in Markdown
| This | Is | A | Table |
| :--- | :-: | - | ---: |
| Here | Is| Some | Info|
  • I learned about the importance of User Stories in building a product
  • Communicating with a team about User Stories realy brings out new ideas
  • Communicating effectively with another person is difficult - we will need to set our goal together, and explicitly agree on every step?
  • It is difficult to look forward without understanding the goal of the entire project