Pipes - Kate Evans-Spitzer - Hotel

[Guribot]

Hotel

Congratulations! You're submitting your assignment!

Comprehension Questions

Question	Answer
Describe a design decision you had to make when working on this project. What options were you considering? What helped you make your final decision?	The biggest design decision my design group struggled with was where Reservations would live - our first pass had the Reservation stored within the Room ("a room has a reservation"), but after some discussion we agreed that it didn't make sense for a Hotel to have to ask its Rooms about a Reservation and they should be stored within the Hotel object.
Describe a concept that you gained more clarity on as you worked on this assignment.	Single-responsibility, especially in methods, and the usefulness of separating specific functionality into Modules where it could be accessed by multiple objects. I found myself trying to do very similar things within different methods and classes, and being able to simplify things by separating repeated actions into their own methods (e.g. adding the #overlap? method to the DateRange module was used in many booking methods)
Describe a nominal test that you wrote for this assignment.	Testing that one reservation could begin the same day the previous one ended: The test books one reservation for one span of dates, then books another beginning the date that the first reservation checks out, then confirms that they have been assigned the same room. Since the program defaults to booking the first available room, these rooms should match.
Describe an edge case test that you wrote for this assignment.	Testing that a reservation could not be shorter than 1 night: The test attempts to book a reservation that begins and ends on the same date. The DateRange method used to check the dates will raise an Exception if the dates passed in do not span at least 1 night, so this test raises an Exception as expected.
How do you feel you did in writing pseudocode first, then writing the tests and then the code?	I had trouble with this - I kept getting ahead of myself and trying to write actual code on my first pass. This led to me having to go back and refactor some methods that I probably would have written more efficiently had I started out in pseudocode.

[droberts-sea]

Hotel

What We're Looking For

Feature	Feedback
Baseline
Used git regularly	yes - good work!
Answer comprehension questions	yes
Design
Each class is responsible for a single piece of the program	yes
Classes are loosely coupled	yes
Wave 1
List rooms	yes
Reserve a room for a given date range	yes
List reservations for a given date	yes
Calculate reservation price	yes
Invalid date range produces an error	yes
Test coverage	yes
Wave 2
View available rooms for a given date range	yes
Reserving a room that is not available produces an error	yes
Test coverage	yes - missing some (see inline), but probably good enough
Wave 3
Create a block of rooms	yes
Check if a block has rooms	yes
Reserve a room from a block	yes
Test coverage	yes
Additional Feedback

Great work overall! Your design is well-thought-out and deliberate, your specific method code is well-organized and easy to read, and your test coverage is solid. Keep up the hard work.

[droberts-sea]

I usually recommend against this sort of argument checking. If the number of rooms isn't an integer, then an error will happen as soon as you get to the times call on the next line. Moreover, this prevents someone from implementing some other class that has a times method and using it here. This is called "duck typing", and it's one of the big ideas that make dynamic languages like Ruby nice to use.

[droberts-sea]

I really like this method - it is well-implemented and very easy to read.

Minor note: you don't need the (rooms.include? reservation.room). Attempting to delete an element from a list in which it doesn't appear will have no effect (not an error).

[droberts-sea]

Good use of an instance method (Block#includes_dates?) to keep things loosely coupled.

[droberts-sea]

I like these test cases! There are many similar cases it might be interesting to explore here around whether or not a room is available. My entire list includes:

• Does Overlap:
  • Same dates
  • Overlaps in the front
  • Overlaps in the back
  • Completely contained
  • Completely containing
• Does Not Overlap:
  • Completely before
  • Completely after
  • Ends on the checkin date
  • Starts on the checkout date

[droberts-sea]

Since you test all this functionality in the context of DateRange, you can get away with just a cursory bit of coverage here. This is important for two reasons:

1. If the functionality changes enough that the tests need to change, you currently need to change them in two places
2. You don't want to burn yourself out writing a bajillion redundant tests.

[droberts-sea]

Good coverage here.