DEV Community: madhur Saluja

Final Post Reflection

madhur Saluja — Thu, 12 Dec 2024 04:43:28 +0000

As this project concludes, I can confidently say that the journey has been transformative both in terms of my technical skills and personal growth. Working individually on this project taught me to handle challenges head-on and pushed me to explore areas outside my comfort zone. Here's a detailed account of what I accomplished, how I tackled obstacles, and what I learned along the way.

Achieving My Goals

At the beginning of this course, my primary goal was to contribute meaningfully to a real-world project while improving my skills in front-end development and testing. Looking back, I’m proud of how far I’ve come. Not only did I manage to contribute new features and improvements to the codebase, but I also learned how to engage effectively with the open-source community.

What I Built

Adding New Features

I implemented a feature in the FeaturesSection component to allow dynamic rendering of feature cards. This required deep diving into React best practices and integrating Framer Motion for animations.

Ensuring the feature aligned with the existing CSS aesthetic was a significant focus. I spent hours refining styles to maintain the visual appeal and cohesiveness of the website. Matching the existing design standards was challenging but rewarding, as the final result blended seamlessly with the original.

Styling Challenges

Adapting my code to fit the established styling conventions of the project was one of the most time-intensive tasks. The project had intricate and polished CSS, and ensuring my additions met this high standard required meticulous attention to detail. I experimented with utility-first CSS approaches and iterated multiple times until it looked perfect.

Unit Testing Implementation

I wrote unit tests for the following components:

BackgroundGradient: Verified child rendering and conditional animation styles.

CardHoverEffect: Ensured all props were rendered correctly and hover interactions worked as expected.

FeaturesSection: Tested responsiveness, card rendering, and empty state scenarios.

Setting up Jest and React Testing Library was a foundational task. This included configuring the test environment and writing meaningful, robust tests. Testing helped identify edge cases and improved overall code reliability.

Community Engagement

One of the most valuable aspects of this journey was learning to engage with the open-source community. I reached out to the project maintainer on Discord to clarify requirements and discuss design decisions. This interaction not only provided insights into the project’s vision but also boosted my confidence in discussing technical ideas with experienced developers.

Challenges and How I Overcame Them

Adapting to Established Code Standards

Initially, understanding and adapting to the existing codebase and styling was daunting. I overcame this by thoroughly analyzing the code, experimenting locally, and referring to documentation.

Learning Communication Skills

As someone new to community engagement, I had to learn how to ask concise yet meaningful questions. By observing community norms and being open to feedback, I improved significantly in this area.

Testing Complex Components

Writing unit tests for components with animations and dynamic states was challenging. For instance, ensuring the FeaturesSection responded to empty states and viewport changes required creative use of testing libraries.

Issue Links-
Issue1
Issue2
PR Links-
PR1
PR2

Lessons Learned

Importance of Standards: Adhering to high CSS and code quality standards improved my attention to detail and ability to deliver polished work.

Community Interaction: Asking the right questions and collaborating with maintainers is as crucial as writing good code.

Test-Driven Development: Writing tests not only identifies potential bugs but also provides clarity on expected functionality.

Moving Forward

This course and project solidified my technical foundation and introduced me to real-world development processes. The decision to take this course was one of the best I’ve made. The lessons learned and skills gained will undoubtedly help me in my career as a software engineer. From coding and testing to communicating effectively, this experience has been a cornerstone of my growth.

Final Thoughts

I’m incredibly proud of the work I accomplished, from implementing new features to matching the project’s aesthetic, writing comprehensive tests, and engaging with the community. This journey has been filled with challenges and learning opportunities, and I’ll carry these experiences forward as I continue to grow as a developer.

Week 2 Progress Update

madhur Saluja — Tue, 10 Dec 2024 07:14:13 +0000

Introduction

This week has been both challenging and productive as I continued working on improving and contributing to the project. Here, I’ll share my progress, what I’ve accomplished, the challenges I faced, and how I plan to adjust to meet my goals by the end of the term.

What I Have Done So Far

Focused on Matching Aesthetic Standards:
- A significant portion of this week was spent ensuring that the CSS styling of the components aligns perfectly with the current aesthetics of the website.
- Matching the website’s established design system required careful attention to detail and iterative adjustments.
- This task was more time-consuming than expected, but it was essential to maintain the visual consistency of the project.
Started Writing Unit Tests:
- I began creating unit tests for critical components of the project using Jest and React Testing Library.
- My main focus has been on components like BackgroundGradient, CardHoverEffect, and FeaturesSection.
- These tests ensure that the components behave as expected under various scenarios, such as rendering correctly, responding to user interactions, and handling edge cases.
Collaboration with the Maintainer:
- I reached out to the project maintainer on Discord to discuss best practices and clarify doubts about the project structure.
- This conversation helped me understand the project’s testing and coding standards better and aligned my contributions with the maintainer's expectations.

Challenges Faced

Matching CSS Standards:
- Adhering to the existing design system took more time than anticipated due to the complexity of the website’s current styling and animations.
- Some minor discrepancies required in-depth research and experimentation with CSS and animations to achieve the desired look and feel.
Writing Comprehensive Unit Tests:
- Creating detailed test cases that cover all edge scenarios was challenging, particularly for components with conditional rendering and animations.
- Understanding how animations and event handlers integrate into the testing framework required additional research.

What I Have Figured Out

CSS Research and Debugging:
- I have developed a better understanding of how to debug and refine CSS to achieve pixel-perfect alignment with existing styles.
- Experimenting with various CSS properties and consulting design resources helped me resolve many styling challenges.
Unit Testing Workflow:
- After some trial and error, I successfully set up Jest and React Testing Library for the project.
- I now have a clear framework for structuring test cases and ensuring all essential behaviors are covered.

Adjusting to Meet My Goals

To stay on track and achieve my goals for this project, I will:

Dedicate specific time blocks to focus on completing the unit tests.
Monitor my progress closely and make adjustments to my plan if needed.

Conclusion

This week has been an excellent opportunity to learn and grow while tackling real-world challenges in a collaborative project. While progress has been slower than anticipated in some areas, I am confident that the foundation I’ve built will allow me to move forward effectively.

I look forward to completing the unit tests and ensuring that my contributions align perfectly with the project’s standards.

Stay tuned for more updates next week as I aim to wrap up the unit testing phase and explore additional opportunities to enhance the project!

Planning Document for Issue #15: Features Section Improvement

madhur Saluja — Tue, 10 Dec 2024 00:07:14 +0000

Motivation and Planning

(edit- I just realized that this blog for planning has been siting in draft from over a week whereas I thought its already posted. Sorry for the late post)

As part of my open-source journey, I decided to work on Issue #15 in the DaabChingrii project. This issue focused on creating, designing and improving the Features Section, ensuring it aligned seamlessly with the rest of the website while incorporating modern animation and styling practices.

Why This Issue?

I specifically chose this issue because it offered a fresh challenge—something I had not attempted before in my open-source contributions. The task required me to learn Tailwind CSS, Framer Motion, and delve into the project's structure. It was a unique opportunity to expand my skillset and contribute meaningful changes to a live project and learning a new Styling tool like Tailwind will also contribute to resume as I have not been to much active in front-end development lately.

Steps I Took

The process involved multiple phases:

Understanding the Project
- The project structure was initially unfamiliar, and I spent time analyzing and comprehending the file organization, component hierarchy, and Tailwind setup.
- I engaged in discussions within the project's Discord channel to clarify doubts about the existing structure and requirements even before officially asking to assign the issue and after getting assigned then I realized that there was conversation of issue page itself due to which I uploaded the final work screenshot there.
Learning the Tools and Technologies
- I had limited to no experience with Tailwind CSS and Framer Motion, so I dedicated time to exploring Tailwind's documentation and experimenting with its utilities for creating responsive layouts and animations.
- Framer Motion's animation principles, especially creating dynamic hover effects and viewport transitions, were new and exciting challenges.
Planning the Solution
- I spent time brainstorming ideas for the redesign. I carefully evaluated various design elements and animation effects to maintain consistency with the project's aesthetic.
- I also researched best practices for accessibility and performance optimization.

Reflection and Next Steps:

I believe that, this issue will prove to be a valuable learning experience. It not only deepened my technical understanding but also enhanced my ability to contribute effectively in an open-source environment.

This work has until now has been both a challenge and a rewarding experience, and I look forward to continuing my contributions to the DaabChingrii community!

Tackling Issue-164: Enhancing VoiceService Tests in React-Chatbotify

madhur Saluja — Mon, 02 Dec 2024 01:44:22 +0000

Introduction

Working on open-source projects often presents unique challenges, and tackling Issue-164 in the React-Chatbotify repository was no exception. The issue involved enhancing and structuring the test coverage for the VoiceService component—a feature that supports both speech recognition and audio recording.

This was my first time testing a voice component with such diverse functionality, and it came with its own learning curve. From understanding someone else's codebase to adapting to their development practices, this experience was both challenging and rewarding.

The Journey

When I first delved into the codebase, I faced the inevitable hurdle of unfamiliarity. Navigating through the VoiceService component, which combines two distinct functionalities (speech recognition and audio recording), felt overwhelming at first. But as I progressed through my open-source development course, I noticed a significant improvement in how I approached these challenges. By the end of the course, I found myself far better equipped to comprehend and work with code written by others.

What Made This Task Unique

The task required creating distinct test cases for two separate functionalities within VoiceService:

Speech Recognition: Ensuring that the component behaves as expected when using SpeechRecognition.
Audio Recording: Testing the functionality related to recording audio via the MediaRecorder API.

Testing a voice component is inherently complex due to dependencies on browser-specific APIs, real-time user input, and error handling scenarios such as microphone access denial. Additionally, mocking these APIs for a controlled testing environment added another layer of complexity.

The Solution

In the Pull Request #279, I implemented the following:

Separate Test Cases: Clearly distinguished between test cases for SpeechRecognition and MediaRecorder functionality to improve clarity and maintainability.
Enhanced Mocks: Mocked browser-specific APIs like navigator.mediaDevices.getUserMedia and SpeechRecognition to simulate real-world scenarios.
Error Handling Tests: Validated how the system responds to common errors, such as microphone access denial or unsupported browser features.
Edge Case Coverage: Included tests for various settings, such as language configuration, timeout behaviors, and user actions.

Each test ensured that the VoiceService handled the respective functionalities gracefully, even in adverse scenarios.

Challenges and Growth

This task wasn't just about writing tests—it was about growing as a developer. Testing a voice component pushed me to think beyond conventional test cases and consider user scenarios that are often unpredictable. More importantly, it reinforced the importance of writing robust and meaningful tests in a collaborative environment.

By the end of this task, I felt a significant boost in confidence. I had effectively solved a real-world problem in someone else's codebase—a milestone in my journey as an open-source contributor.

Reflections

Thanks to the structured learning from my open-source development course, the process of understanding and contributing to unfamiliar codebases has become smoother. While it still demands effort and patience, I now have a systematic approach to tackling such tasks.

Acknowledgments

I'm incredibly grateful for the opportunity to work on this issue and contribute to the React-Chatbotify repository. It was an enriching experience that deepened my understanding of testing and open-source collaboration.

For more details, check out:

Contributing to open-source projects has been one of the most fulfilling parts of my journey as a developer. I look forward to solving more challenges and learning from the vibrant open-source community.

Madhur Saluja

Debugging and Fixing a Complex Jest Test Case in React

madhur Saluja — Thu, 28 Nov 2024 05:38:31 +0000

Introduction

Hi, So Recently, I was working on fixing a Jest test case for a React component. While I had some knowledge about testing, this task proved to be a steep learning curve. The issue involved a ChatMessagePrompt component with multiple contexts and dynamic behaviors. What made it more challenging was my lack of prior experience with testing such complex components using Jest.

In this blog, I'll share the challenges I faced, how I debugged the issue, and the eventual solution. If you're new to Jest or testing complex components, I hope this post will be helpful for you!

The Problem

The ChatMessagePrompt component provides users with a "scroll to bottom" prompt when there are unread messages. It relies on multiple React contexts (BotRefsContext, BotStatesContext, SettingsContext, and StylesContext) for its functionality.

When running the test file, one specific test consistently failed:

FAIL __tests__/components/ChatBotBody/ChatMessagePrompt.test.tsx
ChatMessagePrompt Component
    ✓ renders with the correct message prompt text
    ✕ applies visible class when conditions are met
    ✓ applies hidden class when conditions are not met

The error message indicated:

Expected the element to have class:
  rcb-message-prompt-container visible
Received:
  rcb-message-prompt-container hidden

Challenges Faced

Here are the main challenges I encountered:

Dynamic Context Mocks:
- The component relied heavily on context values. Some tests required unreadCount and isScrolling values to change dynamically, which wasn't happening in my initial implementation.
State Contamination Between Tests:
- unreadCount and isScrolling were global mock variables, leading to cross-test state contamination.
CSS Class Dependencies:
- The visibility of the component depended on CSS classes, and Jest's handling of CSS can sometimes be tricky.
JSDOM Limitations:
- The scrollToBottom function in the component used window.scrollTo, which isn't implemented by JSDOM.
Lack of Jest Expertise:
- I was unfamiliar with advanced mocking techniques in Jest, such as dynamically returning mock values.

The Solution

After hours of debugging and research, here's how I solved the issue:

1. Dynamic Context Mocks

Instead of using global variables for mocking unreadCount and isScrolling, I moved to dynamic mocking within each test. This allowed me to configure the mock values independently for every test.

Updated Code:

jest.mock("../../../src/context/BotStatesContext", () => ({
    useBotStatesContext: jest.fn(),
}));

it("applies visible class when conditions are met", () => {
    (useBotStatesContext as jest.Mock).mockReturnValue({
        unreadCount: 2,
        isScrolling: true,
        setIsScrolling: jest.fn(),
    });

    render(<ChatMessagePrompt />);
    const messagePrompt = screen.getByText("Scroll to new messages");
    expect(messagePrompt.parentElement).toHaveClass("rcb-message-prompt-container visible");
});

2. Cleaning Up Between Tests

I ensured all timers and mock states were reset after each test to avoid cross-test contamination. Here's how I achieved that:

Updated Code:

afterEach(() => {
    jest.clearAllMocks();
    jest.runOnlyPendingTimers();
    jest.useRealTimers();
});

3. Mocking `window.scrollTo`

To handle the window.scrollTo issue, I mocked it globally in my test setup:

Updated Code:

beforeAll(() => {
    Object.defineProperty(window, 'scrollTo', { value: jest.fn(), writable: true });
});

4. Debugging CSS Class Issues

I verified that Jest's CSS mocking was correctly configured in the jest.config.js file. Here's the relevant snippet:

"moduleNameMapper": {
    "\.(css|less|scss|sass)$": "identity-obj-proxy"
}

This ensured that CSS classes like visible and hidden were correctly mocked and recognized in tests.

5. Using Proper Timer Management

The scrollToBottom function used animations (requestAnimationFrame) and timers. I ensured Jest's fake timers simulated this behavior accurately:

Updated Code:

jest.advanceTimersByTime(600); // Simulate the scrolling duration
expect(mockSetIsScrolling).toHaveBeenCalledWith(false);

Final Thoughts

This experience taught me a lot about Jest and testing React components:

How to dynamically mock context values.
The importance of isolating test states.
Handling JSDOM limitations with mocks.
Debugging CSS-related issues in Jest.

Here's the final takeaway: testing complex components isn't just about writing tests but also understanding how the component interacts with its dependencies.

If you're working on a similar problem, don't give up! Testing can be tricky, but it's also incredibly rewarding.

PR Generated

https://github.com/tjtanjin/react-chatbotify/pull/278

Acknowledgments

Although I solved this problem on my own, I want to thank the incredible testing and React communities for their resources and discussions that guided me along the way.

Thanks for reading!

— Madhur

Completing Lab 9 - Releasing Code Complexity Pro

madhur Saluja — Thu, 28 Nov 2024 03:26:52 +0000

Introduction

Releasing software is an art that goes beyond writing good code—it’s about making your tool accessible, easy to install, and user-friendly. In Lab 9, I worked alone to finalize the release of Code Complexity Pro, a Python command-line tool for analyzing code complexity using Groq’s LLM API. This blog walks you through the release process, the challenges I faced, and how I overcame them.

Choosing Tools and Registry

I chose the following tools for the release:

Package Manager: Python’s setuptools for building the package and twine for uploading it.
Registry: PyPI for publishing the production-ready package. Before that, I tested it on TestPyPI.

These tools are industry standards for Python projects, and their documentation provided helpful guidance.

The Release Process

Here’s how I took Code Complexity Pro from development to release:

Tagging the Release:

I created an annotated tag to mark the release version using Git:

 git tag -a v1.1.2 -m "Final production release of Code Complexity Pro"
 git push --follow-tags

Tags allowed me to fix a version snapshot in the repository for easy reference.

Building the Package:
- I used setuptools to create source (.tar.gz) and wheel (.whl) distributions:
```
 python setup.py sdist bdist_wheel
```

These files were stored in the dist/ directory.

Uploading to TestPyPI:
- I first uploaded the package to TestPyPI for testing:
```
 twine upload --repository testpypi dist/*
```

This step ensured the package was functional before going live on PyPI.

Publishing to PyPI:
- After successful testing, I uploaded the package to the official PyPI:
```
 twine upload dist/*
```
Testing Installation:
- I installed the package from PyPI on a clean environment to verify its functionality:
```
 pip install code-complexity-pro
```

Challenges and How I Solved Them

1. Keyring Errors During `twine upload`

Issue: twine threw a NoKeyringError because my environment didn’t support the keyring backend.
Solution: I bypassed the keyring by directly entering the PyPI API token when prompted. Additionally, I configured a .pypirc file for future automation:
```
 [pypi]
 repository = https://upload.pypi.org/legacy/
 username = __token__
 password = <your-api-token>
```

2. `ModuleNotFoundError` in Tests

Issue: My test files couldn’t locate modules due to incorrect import paths.
Solution: I updated all test imports to use fully qualified paths, e.g.,:
```
 from code_complexity_pro.api_handler import send_code_to_groq
```

3. Feedback from User Testing

During testing, it became apparent that lab patner was unsure how to set up API keys. To address this, I added detailed instructions to the README.md on configuring keys via .env or a TOML file.

4. 403 Forbidden on PyPI Upload

Issue: PyPI rejected uploads due to invalid authentication.
Solution: I regenerated an API token on PyPI and used it in the .pypirc configuration file.

What I Learned

Packaging is Critical: Preparing a project for release requires thoughtful structuring of files, dependencies, and configurations.
Documentation Matters: Clear, step-by-step instructions in the README.md can prevent user confusion and ensure smooth adoption.
Testing is Invaluable: Testing the package in environments similar to a user’s setup revealed issues I wouldn’t have caught otherwise.

Changes Made for the Release

To prepare the project for release:

Added a setup.py file for packaging.
Created a .pypirc file for easier uploads to PyPI.
Updated README.md with installation instructions, usage examples, and API key setup.

How Users Can Install and Use Code Complexity Pro

Installation

To install the latest version of Code Complexity Pro, run:

pip install code-complexity-pro==1.1.2

Usage

Analyze code complexity with the following commands:

Analyze a Single File:

   code_complexity_pro --files path/to/file.py --api-key your-api-key

Analyze a Directory:

   code_complexity_pro --files /path/to/directory/ --api-key your-api-key

Save Results to a File:

   code_complexity_pro --files file.py --output analysis_results.txt

For more detailed instructions, check the GitHub Repository.

Conclusion

Completing Lab 9 was a challenging but rewarding experience. It gave me a deeper appreciation for the release process and taught me how to ensure that users can install and use a project effortlessly. By improving documentation, refining configurations, and addressing user feedback, Code Complexity Pro is now a polished tool ready for the Python ecosystem.

Setting Up CI and Writing Tests for Collaborative Development

madhur Saluja — Wed, 20 Nov 2024 04:45:18 +0000

Introduction

In this post, I summarize my experience setting up GitHub Actions for Continuous Integration (CI), writing tests for my own project, and contributing to a partner's repository.

Setting Up GitHub Actions for My Project

To automate testing and linting, I created a CI workflow in .github/workflows/ci.yml. Below is the YAML configuration:

name: Python CI

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.9'

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt

      - name: Run linting
        run: |
          pip install black flake8
          black . --check
          flake8

      - name: Run tests
        run: |
          pytest

Challenges Faced

While setting up CI, I encountered issues with YAML indentation and ensuring that tools like flake8 and black worked well together. Debugging these problems taught me how important it is to have consistent configurations across tools.

Outcome

With CI in place, every commit is automatically tested, and I receive instant feedback on potential issues. This has significantly improved the reliability and maintainability of my project.

Writing Tests for My Partner’s Repository

I collaborated on AutoCommentingTool, a JavaScript-based project. Writing tests for someone else’s project was a unique experience and helped me understand the importance of clear documentation and modular code.

Key Differences

My Project: Python-based with pytest, black, and flake8.
Partner’s Project: JavaScript-based with Mocha, Chai, and Sinon.

Tests Written

I focused on testing file operations (writeIntoFile) and contributed additional test cases for edge cases such as empty strings, nested paths, and handling write failures.

Here’s a test I wrote for file operations in the repository:

it('should throw an error if writing to the file fails', async function () {
    const testData = 'This is a test comment.';
    const testFileName = 'testOutput.js';

    writeFileStub.yields(new Error('Write failed'));

    try {
        await writeIntoFile(testData, testFileName);
        throw new Error('Expected error was not thrown');
    } catch (err) {
        expect(err.message).to.equal('Write failed');
    }
});

Challenges Faced

Understanding unfamiliar code and framework setups.
Adjusting to a different language (JavaScript) and testing tools (Mocha/Chai).

Lessons Learned

A well-documented project is crucial for onboarding contributors.
Writing modular and testable code makes it easier for others to add tests.

Reflections on CI

Setting up CI and experiencing its benefits firsthand has transformed how I approach development. Here’s what I learned:

Time Savings: Automating tests saves time by catching issues early.
Quality Assurance: CI enforces consistency and ensures that only well-tested code is merged.

Collaboration: CI simplifies collaboration by providing a clear picture of the project’s health.

I now see CI as an essential part of software development. It might take time to set up, but the benefits outweigh the initial effort.

Conclusion

This project was a valuable learning experience that improved my understanding of CI, testing, and collaboration. Setting up CI for my project made it more reliable, while contributing to a partner’s project helped me grow as a developer.

I look forward to applying these skills in future projects and advocating for the use of CI in team settings to improve code quality and collaboration.

Writing Effective Tests for My Code Complexity Analyzer: A Deep Dive

madhur Saluja — Sun, 10 Nov 2024 03:28:52 +0000

Testing is an essential part of software development that often takes a back seat to feature building. But as I recently learned, good tests do more than just catch bugs—they make your code resilient, modular, and a lot easier to maintain. In this post, I’ll walk through my recent experience setting up and running tests for my Code Complexity Analyzer project, including which tools I used, how I tackled mocking responses from a Large Language Model (LLM) API, and the lessons I picked up along the way.

Choosing a Testing Framework and Tools

For this project, I chose the following tools:

pytest: A powerful testing framework for Python, pytest is flexible and easy to use, with a large community and plenty of plugins. Its clear syntax and support for complex testing scenarios made it a natural choice for this project.
pytest-watch: To speed up development, pytest-watch automatically re-runs tests when files change. This tool has proven invaluable for TDD (Test-Driven Development) workflows.

Each tool serves a unique role in the testing process. While pytest is the main framework, pytest-watch allows for an efficient feedback loop when running tests. Using these tools in combination helped create a seamless and effective testing environment.

Setting Up the Tools

Here’s how I set up these tools in my project:

Install and Configure: I added pytest and pytest-watch to the project’s requirements.txt file. This ensured that any developer working on the project could install them easily.
Using the Makefile: I added targets in the Makefile for running all tests, running a single test, and automatically rerunning tests on file changes. Here’s a snippet of the Makefile:

   test:
    $(TEST_RUNNER)
    pytest
    # Run a specific test file or function
    test-one:
        @if [ -z "$(TEST)" ]; then \
            echo "Please specify a test file or function with TEST=<file>::<function>"; \
        else \
            pytest $(TEST); \
        fi
    # Automatically rerun tests on file changes
    watch:
        @echo "Watching for file changes... Press Ctrl+C to stop."
        @while inotifywait -r -e modify,create,delete ./; do \
            clear; \
            pytest; \
        done

With these commands, I could easily run all tests, target specific tests, and set up an automatic test rerun on file changes. This setup kept my workflow fast and the codebase reliable as I iterated on the project.

Mocking LLM Responses

One of the unique challenges of this project was dealing with responses from an external LLM API. Testing directly against the live API would be slow, brittle, and dependent on network stability and API credits. Instead, I used mocking.

To simulate API responses, I used unittest.mock in pytest to mock the HTTP responses from the LLM API. This way, I could control the response data and ensure that tests would run consistently.
This approach allowed me to simulate both successful and error responses from the API, testing how the code handles different scenarios without relying on real API calls.

Learning from the Testing Process

Writing test cases made me think critically about my code’s structure and exposed areas for improvement. For example, I initially designed the code with a CLI focus, but breaking down functionality into smaller, testable functions improved test coverage and made the code more modular and maintainable.

Key Takeaways and "Aha!" Moments

Testing Forces Modular Design: Splitting code into smaller, focused functions improved both the readability and testability of my code. I had to rework some of my initial code to create functions that were easier to test, and this made the project more flexible and reliable.
Edge Cases Matter: Testing exposed edge cases I hadn’t considered initially, such as handling empty strings or invalid API keys. Mocking responses let me simulate these cases effectively, which highlighted how the code would handle real-world scenarios and prevented potential bugs from going unnoticed.
The Power of Automation: Using pytest-watch to automatically rerun tests on file changes streamlined my workflow. Tools like these are game-changers for productivity, and I plan to use them in all future projects.

Bugs and Surprises

During testing, I discovered a few minor bugs, particularly around error handling. For instance, without a valid API key or with a misconfigured endpoint, the code initially didn’t handle the error gracefully. Adding tests forced me to write better error messages and handle unexpected input more robustly.

Reflections and Future Testing Plans

This project was a great introduction to automated testing for me. I’ve tested code before but usually informally, by manually running it and observing the output. This experience taught me the value of structured, automated testing. Testing ensures that each change improves the code without introducing new bugs, and it’s particularly important for team environments where multiple developers work on the same codebase.

In the future, I’ll be much more intentional about writing tests early in the development process. Building testability into the design from the start and using tools like pytest and pytest-watch will save time and improve code quality in the long run.

Final Thoughts

Automated testing might seem daunting at first, but the time saved and the peace of mind gained are invaluable. I hope this post helps other developers see the benefits of testing frameworks, and that my setup process offers a clear starting point for those looking to implement similar tools in their projects.

Simplifying Development with Automation and Consistency – Lab 6 Walkthrough

madhur Saluja — Sun, 03 Nov 2024 04:40:07 +0000

Welcome to the Lab 6 journey! This blog post covers everything I did to enhance the Code Complexity Pro project by integrating automation, setting up a consistent code style, and making it super easy for any contributor to dive in. Let's explore the tools I used, why I chose them, and how they improve our workflow!

📌 Goal: A Consistent, Automated Development Environment

When working on a project with multiple contributors, consistency is critical. Without a unified coding style and automated checks, code can become difficult to maintain and read. Lab 6 is all about establishing a consistent, automated environment using tools for:

Code Formatting: Enforcing a consistent style across the codebase.
Linting: Identifying coding issues early to ensure quality and readability.
Automation: Simplifying repetitive tasks like formatting, testing, and installation.

Let's dive into how I set up each part and why it’s important!

🔍 Step 1: Choosing Black as Our Code Formatter

Why Black?
Black is an “uncompromising” code formatter for Python, meaning it enforces strict coding standards without much customization. This is a big plus since it keeps the codebase consistent without room for stylistic debates.

What We Did:

Installed Black in my project to automate code formatting and ensure consistent styling.
Configured Black to format code with an 88-character line length, which is ideal for readability and matches industry standards.

Result: Now, whenever we save our files, Black ensures they are formatted to match the project’s style, which helps us avoid formatting-related commits and reviews.

🔍 Step 2: Adding Flake8 as Our Linter

Why Flake8?
Flake8 is a popular linter that checks for PEP 8 compliance and other common Python coding issues. It identifies syntax errors, unused imports, and other problems that can make code error-prone or harder to read.

What We Did:

Configured Flake8 to run automatically and check our code.
Set up Flake8 to match Black’s line length (88 characters) to avoid conflicts.
Ignored certain rules that overlap with Black’s formatting to streamline our setup.

Result: Flake8 helps us catch small issues before they become big problems, improving code quality while we work.

🔍 Step 3: Creating a .blackignore File

Why .blackignore?
The .blackignore file allows us to specify files and folders that we don’t want Black to format. This is useful for excluding version control folders, virtual environments, and other files that don’t require formatting.

What We Did:

Created a .blackignore file in the root of the project and added directories to exclude from formatting, such as:

  # .blackignore
  .git/
  __pycache__/
  venv/
  .venv/
  build/
  dist/
  .vscode/

Result: Black now ignores these folders, focusing only on the source code we are actively developing, which speeds up formatting and keeps the output clean.

🔍 Step 4: Automating with a Makefile

Why a Makefile?
A Makefile is a convenient way to bundle common tasks into simple commands. Instead of running multiple commands manually, we can use make commands to format, lint, test, and install dependencies with ease.

What We Did:
We created a Makefile with the following commands:

format:
    black .

lint:
    flake8 .

test:
    pytest

install:
    pip install -r requirements.txt

make format: Runs Black to format all code.
make lint: Runs Flake8 to check for code issues.
make test: Runs tests to ensure everything works.
make install: Installs dependencies from requirements.txt.

Result: With this Makefile, contributors can easily follow project standards by using simple commands.

🔍 Step 5: Setting Up Editor Integration with `.vscode/settings.json`

Why Editor Integration?
Automating formatting and linting within the editor helps maintain code standards in real-time. When settings are applied universally in .vscode/settings.json, all contributors using VS Code get the same experience.

What We Did:

Created a .vscode/settings.json file to enforce the same setup across contributors.
Configured settings to automatically format with Black and lint with Flake8.

{
  "python.formatting.provider": "black",
  "editor.formatOnSave": true,
  "python.linting.flake8Enabled": true,
  "python.linting.enabled": true,
  "python.formatting.blackArgs": ["--line-length", "88"],
  "python.linting.flake8Args": ["--max-line-length=88", "--ignore=E203,E266,E501,W503"],
  "files.exclude": {
    "**/__pycache__": true,
    "**/.git": true,
    "**/.vscode": true,
    "**/venv": true
  }
}

Result: This setup ensures that formatting and linting happen automatically, so contributors don’t have to remember to run them manually.

🔍 Step 6: Adding a Git Pre-Commit Hook

Why a Pre-Commit Hook?
Pre-commit hooks automatically run checks before changes are committed. This ensures that any code added to the repository adheres to our formatting and linting rules.

What We Did:

Installed pre-commit and set it up to run Black and Flake8 before each commit.

To set up pre-commit, we added a .pre-commit-config.yaml file with the following configuration:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/psf/black
    rev: 22.3.0  # Use the latest Black version
    hooks:
      - id: black
        args: ["--line-length", "88"]
  - repo: https://github.com/pycqa/flake8
    rev: 4.0.1  # Use the latest Flake8 version
    hooks:
      - id: flake8
        args: ["--max-line-length=88", "--ignore=E203,E266,E501,W503"]

After creating the config file, we ran:

pre-commit install

Result: Now, every time we make a commit, Black and Flake8 run automatically, preventing non-compliant code from being committed.

🔍 Step 7: Cleaning Up Commits with Git Rebase and Squash

Why Rebase and Squash?
When working on a feature branch, it’s easy to end up with multiple commits. Squashing commits into a single one makes the commit history cleaner, making it easier to review and track changes.

What We Did:

Used git rebase -i to squash all commits on the lab6 branch into one.
Merged the squashed commit into main and pushed it to GitHub.

Result: Our commit history is now clean, making it easy to track the single, consolidated change for Lab 6.

📘 Final Thoughts

In Lab 6, I set up a unified, automated workflow that enforces consistent formatting, catches errors early, and streamlines collaboration. Contributors can now easily follow project standards, making the codebase cleaner and easier to maintain.

I hope this setup will help keep Code Complexity Pro organized and welcoming to new contributors. Happy coding! 🚀

Hacktoberfest Adventure with `react-chatbotify`: From Shifted Issues to Success! 🎉

madhur Saluja — Thu, 31 Oct 2024 23:49:49 +0000

For my last Hacktoberfest contribution, I tackled an issue with react-chatbotify, which was a thrilling shift from my original assignment. I initially had another issue, but after two weeks without hearing back from the project owner, I decided it was time for a new challenge. That’s how I stumbled upon issue #223, which was all about supercharging the ChatBotLoader component with new tests. Let’s dive in! 🚀

💥 The Issue at Hand

The issue #223 was a call to action for expanding test coverage on the ChatBotLoader component. This component is like the bot's brain loader—it initializes key configurations, styles, themes, and plugins. The goal? To make sure this component performs flawlessly in every scenario!

🔧 Getting Set Up

My first task was setting up the local environment to run the react-chatbotify repository smoothly. I peeked into existing tests to understand the project’s testing structure, and it clicked. Once I got the hang of it, I was ready to take on the ChatBotLoader. Even though I was initially assigned to a different issue, I quickly adapted to this new one—it was refreshing and pushed me to learn a lot!

🚀 What I Learned

This issue was a treasure trove of learning opportunities, especially around testing components that use multiple contexts and props in React. The ChatBotLoader, in particular, interacts with various contexts like BotRefsContext, BotStatesContext, and more. I needed to mock these contexts to keep the tests isolated and to focus on the component's behavior.

I also had a fun encounter with the emitRcbEvent function and RcbEvent.PRE_LOAD_CHATBOT (sounds fancy, right? 😆). This allowed me to dive into event testing, both before and after configuration loading.

🧩 Breaking Down the Code Fix

Here's a high-level breakdown of each test I worked on:

🔗 Flow Reference Update: This test made sure the flowRef updates correctly with the given flow prop. By mocking flowRef and verifying that it received the correct flow data, the test proved that the component properly sets up the flow.
🚀 Pre-Load Event Emission: This test checked that the rcbPreLoadChatBot event fired just before the configuration load. Mocking the function’s return allowed me to simulate this event and verify emitRcbEvent was doing its thing.
🎨 Theme Change Reloads Config: Here, I added a new theme to the list and watched for the config reload. This test checks how the component reacts to prop changes, ensuring that every time a new theme is introduced, the component reloads.
🎉 Post-Load Event Emission: Similar to the pre-load event, this one verified that rcbPostLoadChatBot triggered after the configuration loaded successfully, giving it a nice little “thumbs up” for a job well done.

💡 Challenges & Research

I have to admit, working with emitRcbEvent threw a few curveballs. The defaultPrevented attribute required special attention, and I had to mock return values to make sure everything interacted correctly.

And of course, mocking hooks and services to test the component without breaking it required some serious sleuthing. I went down a few rabbit holes researching testing techniques, especially around context-heavy components, but it was worth every second.

🎯 Final Thoughts & Next Steps

I’m waiting for the green light from the project owner to make sure these tests hit the mark. As soon as I get the nod, I'll submit my PR here - Add unit tests for ChatBotLoader (link to come!).

The Takeaway

Working on this issue showed me the flexibility needed in open-source projects. Switching from one issue to another, adjusting to unfamiliar code, and learning new testing methods all made this journey one for the books. I’m already pumped for the next adventure!

Thanks for following along, and here's to many more coding quests! 🎉👨‍💻👩‍💻

A Fun Take on Enhancing the Meal Selector CLI Tool

madhur Saluja — Thu, 31 Oct 2024 19:08:48 +0000

Working on a Meal Selector CLI Tool sounded like a quick and easy project, right? A simple random meal generator, ideal for those indecisive days. However, as I dove into the details, I thought, “Why not make it even more interesting?” And that’s how we ended up enhancing this tool to not only provide meal suggestions but also to make it calorie-conscious for users with specific dietary goals. This turned out to be a great little upgrade that combined utility with a touch of personalization.

Here’s a look at how I took on Issue #105 and added some fun, useful features along the way. Let’s dive in!

The Initial Idea

The original concept for the Meal Selector CLI Tool was straightforward: randomly pick an appetizer, main course, and dessert from predefined lists and serve up a meal suggestion for the day. It’s a great idea for people who love variety or just can’t decide on what to eat! The first version was designed to keep things simple, offering a random meal suggestion each time the script runs.

But Wait, Let’s Add Some Calorie Control!

As I was working on the basic setup, an idea popped up: what if users could specify how many calories they want for the day, and the tool could create a meal that meets (or at least stays under) that target? This led to adding a few new features, which made the tool not only a meal generator but also a mini dietary planner!

In came the calorie-based meal selection feature. Each food item got an associated calorie count, which meant that our list of items became slightly more sophisticated but added a ton of value for users. Now, users could enter a target calorie count, and the tool would generate a meal that met their requirements. A few tests, some debugging, and voila — we had a calorie-aware meal selector!

Minimum Calorie Requirement: No More 100-Calorie Days

One quick snag we encountered was when users entered very low calorie limits, like 100 or 200. Obviously, generating a full meal with such low calories isn’t realistic, so we added a minimum calorie notification. The tool now calculates the lowest possible calorie count for a meal (based on the least calorie-dense items) and prompts users to enter a number above this minimum if they go too low.

This way, the tool ensures a more enjoyable (and realistic) user experience by making sure the calorie goal is achievable.

The Final Touches: Visual Appeal and User Guidance

To make the tool even more enjoyable to use, I added some color-coded output using the colorama library. Each part of the meal is displayed with its name and calorie count, alongside a total calorie tally. This makes the output not only functional but also visually appealing, giving users a more engaging experience.

On top of that, the error handling was refined to guide users smoothly through the tool, especially when inputting calorie limits. All these updates came together to provide a tool that’s both simple and fun to use — and more useful than just a basic randomizer.

Wrapping It Up

So there you have it! What started as a simple 100-lines-of-code project turned into a feature-rich, personalized meal suggestion tool. With Issue #105 resolved and the PR #247 merged, we now have a tool that not only picks a meal for you but also lets you stay mindful of your calorie intake.

Next time you’re unsure what to eat, just fire up the Meal Selector CLI Tool, set your calorie goal, and let it surprise you. It’s a great example of how a small project can turn into something useful with just a few thoughtful additions. Happy meal planning!

Fixing Rounded Borders for Blog Previews: A Journey Through CSS and HTML

madhur Saluja — Thu, 31 Oct 2024 18:57:46 +0000

Issue #110: Round the Left Border of Blog Previews

Pull Request #123

First off, a quick apology for the delay in getting this blog post out! This little task of rounding off a few borders took me on a grand tour through the codebase of OpenElements’ website. What started as a “simple” visual tweak quickly turned into a full-blown exploration. But hey, no challenge left unrounded, right?

The Issue: Smooth and Rounded, All the Way Around

Here’s the scoop: the blog previews on OpenElements are supposed to look neat and consistent, with rounded borders on all sides. But there was a hitch—the left border was stubbornly squared off! It may sound like a tiny detail, but design is all about the little things. So I rolled up my sleeves and dived in.

The Journey: CSS, HTML, and the Quest for the Perfect Border

To start, I combed through the style.css file where most of the site’s styling lives. Since this wasn’t my usual haunt, I had to carefully review each class, container, and style that could possibly impact the blog previews’ borders. Think of it as a game of hide-and-seek, but with almost 5000 lines of code!

The main challenge? Figuring out exactly where the left border styling was controlled. This meant cross-referencing and analyzing not only the CSS but also the HTML files like list.html and single.html that handled blog layouts. It was a code detective’s dream—or maybe nightmare—situation.

The Solution: A Border Makeover

After some back-and-forth, I pinpointed the right container and style that needed tweaking. It was just a small change in style.css, but it made all the difference, ensuring the left border would finally match its rounded friends on the right.

Testing the Waters

With the change in place, I hit refresh on every blog preview I could find to confirm everything was working as it should. Sure enough, the borders were finally rounded on all sides, giving the blog previews a smoother, more polished look. Mission accomplished!

Lessons Learned

The big takeaway here? Even minor design adjustments can take you through a deep dive of a codebase, especially when it’s someone else’s project! This pull request gave me a chance to untangle and understand OpenElements’ styling setup, one line at a time. It’s all about getting the details just right, even if it takes a little extra time.

Check out the full Pull Request here to see the updates in action!

DEV Community: madhur Saluja

Final Post Reflection

Achieving My Goals

What I Built

Adding New Features

Styling Challenges

Unit Testing Implementation

Community Engagement

Challenges and How I Overcame Them

Adapting to Established Code Standards

Learning Communication Skills

Testing Complex Components

Lessons Learned

Moving Forward

Final Thoughts

Week 2 Progress Update

Introduction

What I Have Done So Far

Challenges Faced

What I Have Figured Out

Adjusting to Meet My Goals

Conclusion

Planning Document for Issue #15: Features Section Improvement

Motivation and Planning

Why This Issue?

Steps I Took

Reflection and Next Steps:

Tackling Issue-164: Enhancing VoiceService Tests in React-Chatbotify

Introduction

The Journey

What Made This Task Unique

The Solution

Challenges and Growth

Reflections

Acknowledgments

Debugging and Fixing a Complex Jest Test Case in React

Introduction

The Problem

Challenges Faced

The Solution

1. Dynamic Context Mocks

Updated Code:

2. Cleaning Up Between Tests

Updated Code:

3. Mocking window.scrollTo

Updated Code:

4. Debugging CSS Class Issues

5. Using Proper Timer Management

Updated Code:

Final Thoughts

PR Generated

Acknowledgments

Completing Lab 9 - Releasing Code Complexity Pro

Introduction

Choosing Tools and Registry

The Release Process

Challenges and How I Solved Them

1. Keyring Errors During twine upload

2. ModuleNotFoundError in Tests

3. Feedback from User Testing

4. 403 Forbidden on PyPI Upload

What I Learned

Changes Made for the Release

How Users Can Install and Use Code Complexity Pro

Installation

Usage

Conclusion

Setting Up CI and Writing Tests for Collaborative Development

Introduction

Setting Up GitHub Actions for My Project

Challenges Faced

Outcome

Writing Tests for My Partner’s Repository

Key Differences

Tests Written

Here’s a test I wrote for file operations in the repository:

Challenges Faced

Lessons Learned

Reflections on CI

Conclusion

3. Mocking `window.scrollTo`

1. Keyring Errors During `twine upload`

2. `ModuleNotFoundError` in Tests

🔍 Step 5: Setting Up Editor Integration with `.vscode/settings.json`