Jou-Jou's Bank Account

[jjousun]

Bank Account

Congratulations! You're submitting your assignment.

Comprehension Questions

Question	Answer
Why is it useful to put classes inside modules? What do you think?	I think putting classes insides of modules is a way to bundle together classes that are related to each other. That way, Ruby knows which class we're referring to, which is important especially if we've named something the same name.
What is accomplished with raise ArgumentError? What do you think it's doing?	I think raise ArgumentError gives an error message that is specifically telling you that your argument (usually the input for the method parameter) is wrong. You can have it output a message saying exactly what is wrong.
Why do you think we made the .all & .find methods class methods? Why not instance methods?	These methods should be class methods because they have to do with class, not instances of the class - this piece of the class will always be the same for every instance of the class. Specifically, every instance of an account is created from all the information contained in the CSV file (.all), and similarly, .find needs to check all the accounts to give you the right instance of the Account you looked for.
Why does it make sense to use inheritance for the different types of accounts?	Because savings accounts and checking accounts are types of accounts. So there are methods and attributes in each that will be true for all accounts. By defining those methods and attributes for all accounts, we can have subclasses inherit the common behaviors, and then modify each for their own unique behaviors and attributes.
Did the presence of automated tests change the way you thought about the problem? How?	Definitely, yes! It was a struggle, certainly at first, for me to create the tests prior to writing the code. However, I think creating tests first often helped shaped the subsequent code. It still feels kind of resistant, a bit backwards, to do TDD. But it makes you think about the possibilities first, and I can see how that could make your code better.

[kariabancroft]

Bank Account

What We're Looking For

Feature	Feedback
Wave 1
All provided tests pass	Yes
Using the appropriate attr_ for instance variables	Yes
Wave 2
All stubbed tests are implemented fully and pass	Yes. You should split out the all tests into separate it blocks. Right now, this one test has too many assertions. We want to group assertions only when the results of them would directly impact a specific result. I don't think you need the before block in your find tests since you're not using this @accounts instance variable at all in these tests.
Created instances (by calling new) in Account.all	Yes
Used CSV library only in Account.all (not in Account.find)	Yes
Used Account.all to get account list in Account.find	Yes
Wave 3
Used inheritance in the initialize for both Checking and Savings Accounts (min balance)	Not quite. You are using a constant to manage some of the fees throughout but you are duplicating the logic for the min balance. This is potentially another opportunity to use a constant.
Used inheritance for the withdraw in checking and savings accounts	No - overwriting the withdrraw logic rather than reusing pieces from Account class
Tests	Nice job using a before block for your .new to DRY up the tests. Nice job using loops for duplicating logic in the check withdrawal tests. Nice job overall on your Savings and Checking tests!
Baseline
Used Git Regularly	Yes - you did a really nice job with the frequency and the messages.
Answer comprehension questions	Yes - great job with these. I like the way you described your experiences with TDD.