Credit Check Recheck

Credit Check once more!

By now, we should have a solid understanding of the algorithmic requirements behind solving Credit Check in Ruby.

Let’s take our comfort with our solutions, toss them to the side, and start fresh by test-driving the development towards our solution.

Learning Goals

• Follow your errors to create next steps when developing
• Write an algorithm using classes and methods

Vocabulary

• Error Message
• Test Driven Development (TDD)
• Don’t Repeat Yourself (DRY)
• Single Responsibility Principle (SRP)

WarmUp

• Why do we TDD?
• What are the pros/cons of using tests to drive your development?
• What do you find particularly challenging about implementing TDD?
• What are the differences between unit and integration tests?

Setup

Within your projects directory, create a new directory called credit_check_recheck.

Leveraging your knowledge of Ruby project conventions, set yourself up with lib/ and test/ directories.

TDD-ing

Do your best not to write any lines of source code without a test’s error driving you to do so.

Using both unit and integration tests (predominantly unit tests), drive yourself to a modular, OOP Credit Check solution.

If you achieve this during our class time, do your best to revist your source code and make refactors to keep your code as DRY (Don’t Repeat Yourself) and SRP (Single Responsibility Principle)-abiding as possible.

Remember, red, green, refactor, repeat.

You may refer back to your first Credit Check solution, but refrain from copying any code from there to use in this solution.

Closing

• What are some common error messages and what do they lead you to implement in your code?
• Do you find the red, green, refactor pattern helpful? Why or why not?
• How do you feel about Test Driven Development?