Qory Iteration 3 Completed_ Resubmit # 4

Gemfile.lock

@@ -29,6 +29,7 @@ GEM
 PLATFORMS
   arm64-darwin-20
   arm64-darwin-21
+  arm64-darwin-24
 
 DEPENDENCIES
   faraday

Iteration_1.md

@@ -0,0 +1,57 @@
+# Iteration 1 - Learning the Existing Codebase
+
+## Overview
+In this iteration, I explored the existing codebase and familiarized ourselves with the classes, methods, and tests already in place. The goal was to identify any bugs in the application code and debug the project until all tests passed.
+
+# Iteration 1 - Learning an Existing Codebase
+
+## Logic and Implementation of the Registrant Class
+
+In this iteration, I implemented the `Registrant` class to represent a user of the DMV system. The class has the following key features:
+
+- **Attributes**: `name`, `age`, `permit`, and `license_data`.
+  - **Permit** defaults to `false` if not provided.
+  - **License Data** is initialized as a hash with three keys: `:written`, `:license`, and `:renewed`, all defaulting to `false`.
+
+- **Methods**:
+  - `permit?`: Checks if the registrant currently holds a permit.
+  - `earn_permit`: Allows the registrant to earn a permit, updating the `permit` attribute from `false` to `true`.
+
+---
+
+## Test-Driven Development (TDD) Process
+
+1. **Step 1: Write Tests for Initialization**:
+   I started by writing tests to verify that the `Registrant` class correctly initializes with a name, age, and optional permit. The default values for the `license_data` hash were also tested.
+
+2. **Step 2: Implement the Class**:
+   After writing the tests, I implemented the class to make the tests pass. This included:
+   - Defining an initializer method that accepts `name`, `age`, and `permit` (with a default value of `false`).
+   - Initializing the `license_data` hash to track the registrant’s progress through the DMV process.
+
+3. **Step 3: Write Tests for Permit Functionality**:
+   I added tests to verify the behavior of the `permit?` and `earn_permit` methods. These methods control whether a registrant has earned their permit and allow this status to be updated.
+
+4. **Step 4: Implement Permit Logic**:
+   I implemented the `permit?` method to return the status of the permit and the `earn_permit` method to update the `permit` attribute to `true`.
+
+---
+
+## Test Failures and Fixes
+
+1. **Test: Initialization**  
+   - **Failure Reason**: Missing attributes during initialization.
+   - **Fix**: Added the required parameters (`name`, `age`, and `permit`) to the `Registrant` class initializer.
+
+2. **Test: Permit Status**  
+   - **Failure Reason**: Initially, the `permit` attribute was not correctly initialized as `false`.
+   - **Fix**: Set `permit` to default to `false` unless otherwise provided in the initializer.
+
+3. **Test: License Data**  
+   - **Failure Reason**: The `license_data` hash was not initialized correctly.
+   - **Fix**: Ensured the `license_data` hash is always initialized with default values (`false` for `:written`, `:license`, and `:renewed`).
+
+## Reflection
+- **Steps to Explore Codebase**: To explore the codebase, I first reviewed the structure of the provided classes and methods, focusing on how the Facility and Vehicle classes interacted. I read through the initial tests to understand the expected behavior. Using binding.pry, I paused execution at key points to inspect objects and variables, which helped me visualize how data flowed through the code. Finally, I worked through any failing tests one by one, debugging and adjusting the application logic to make them pass.
+- **Challenges**: One challenge was getting familiar with the code that I didn’t write myself, especially when it came to understanding how different methods and objects were interacting. Some logic wasn’t immediately clear, so I had to spend extra time debugging. It was also challenging to extend the functionality without breaking the existing structure.
+- **What was Easier**: It was easier than expected to work with the tests once I understood how the existing structure was built. The well-structured nature of the tests helped me see where new functionality needed to be added. Using binding.pry also made it easier to debug by allowing real-time inspection of object states, which gave quick feedback when something wasn’t working as expected.

Iteration_2.md

@@ -0,0 +1,34 @@
+# Iteration 2 - Adding Features and Creating Objects from Data Sources
+
+## Overview
+In this iteration, the focus was on enhancing the system's capabilities by adding the `Registrant` class and establishing its interaction with the `Facility` class. This allows for better management of users and their interactions with DMV services, particularly in the context of vehicle registration and testing processes.
+
+## New Classes and Methods
+- **Registrant Class**: 
+  - Created to manage user data, including attributes such as name, age, permit status, and license data.
+  - **Methods Added**:
+    - `earn_permit`: Updates the registrant’s permit status based on their age.
+
+- **Facility Class Updates**:
+  - Added methods for administering written tests and road tests to registrants, thereby enhancing the functionality of the facility in relation to user registration and licensing processes.
+
+## Test Failures and Fixes
+1. **Test**: Testing the `earn_permit` method for the `Registrant` class.
+   - **Failure Reason**: Initial tests failed because the logic to determine permit eligibility was not correctly implemented.
+   - **Fix**: Adjusted the logic in the `earn_permit` method to properly set the permit status based on age criteria.
+
+2. **Test**: Administering written tests in the `Facility` class.
+   - **Failure Reason**: Tests for `administer_written_test` failed when checking conditions for age and permit status.
+   - **Fix**: Updated the method logic to correctly evaluate eligibility for taking the written test.
+
+## TDD Process
+- Followed a Test-Driven Development (TDD) approach by writing tests for the `Registrant` and `Facility` functionalities before implementing the corresponding methods.
+- Each test failure guided the development of specific functionality, ensuring that the implemented features aligned with expected outcomes.
+
+## Reflection
+- **Steps to Add Classes**: The process involved defining the `Registrant` class and its attributes, writing tests for the class, and implementing the required methods based on those tests.
+- **Challenges**: A challenge was managing the relationships between classes and ensuring that the logic for eligibility was clear and correctly implemented. There were also difficulties in maintaining existing logic while adding new features.
+- **Successes**: Successfully establishing the interaction between `Registrant` and `Facility` classes was a major win. The use of binding.pry was particularly helpful in debugging and understanding how the new features integrated with existing code.
+
+
+

Iteration_3.md

@@ -0,0 +1,35 @@
+# Iteration 3 - Creating Objects from Multiple Data Sets and Analyzing Our Data
+
+## Overview
+In this iteration, the focus was on creating `Facility` objects from external data sources. We implemented functionality to parse data about DMV facilities and integrate it into our existing system. This allows for improved management of facility information and enhances user experience.
+
+## New Features Implemented
+- **FacilityFactory Class**: 
+  - Created to facilitate the instantiation of `Facility` objects from external data sources.
+  - **Method Added**:
+    - `create_facilities`: Takes an array of data representing facilities and returns an array of `Facility` objects.
+
+- **Integration with DmvDataService**:
+  - Extended functionality to fetch data from multiple states (Colorado, New York, and Missouri) and create `Facility` objects from that data.
+
+## Test Failures and Fixes
+1. **Test**: Creating facilities from data.
+   - **Failure Reason**: Initial tests failed due to improper handling of missing attributes in the data returned from the external API.
+   - **Fix**: Adjusted the `create_facilities` method to handle cases where some expected attributes might be missing or formatted differently.
+
+2. **Test**: Integration with DmvDataService.
+   - **Failure Reason**: Tests for data integration failed when the expected number of facilities did not match the actual output.
+   - **Fix**: Modified the test data setup to align with the actual data format returned by the API.
+
+## TDD Process
+- Employed a Test-Driven Development (TDD) approach by first writing tests for the `FacilityFactory` class and its interaction with the `DmvDataService`.
+- The tests guided the development of new methods to ensure they met the expected requirements and correctly handled the provided data.
+
+## Reflection
+- **Steps to Add Classes**: The process involved defining the `FacilityFactory` class, implementing the `create_facilities` method, and writing tests to validate that the method behaves correctly with various inputs.
+- **Challenges**: One challenge was understanding the structure of the data returned from the API and ensuring that it aligned with how we wanted to create `Facility` objects. Parsing and managing the data effectively required careful consideration.
+- **Successes**: Successfully integrating external data sources into our application was a significant achievement. The new `FacilityFactory` class streamlined the process of creating facility objects, making the system more robust and adaptable to new data.
+
+# From Mentor:
+##### DMVdata will come as potentially 1,000 arrays.
+##### The challenge here is to organize the data. Assign arrays to class objects

Iteration_4.md

@@ -0,0 +1,7 @@
+# Iteration 4 - Refactoring and Final Testing
+
+<<<<<<< HEAD
+##### I did not attempt. Time did not permit.
+=======
+##### I did not attempt. Time did not permit.
+>>>>>>> origin/main

README.md

@@ -1,3 +1,4 @@
 # The DMV
 
-This is the starter repo for the BE Mod1 DMV project.
+Repo for the SE Mod1 DMV project. 
+By Qory