Vish's Journey in Computer Science

recent posts

about

  • Testing with Stubs in Software Quality Assurance

    As part of my Software Quality Assurance and Testing course, I recently explored the concept of testing with stubs. To deepen my understanding, I referred to the article “Test Doubles: Stubs, Mocks, and Fakes” from Martin Fowler’s website.
    Link: https://martinfowler.com/bliki/TestDouble.html

    This resource explains different types of test doubles, including stubs, and how they are used when testing dependent components. A stub is a simplified implementation of a class that returns predefined values, allowing us to test another class even when its dependencies are incomplete or not yet implemented. The article also distinguishes between behavior-based testing (checking interactions between objects) and state-based testing (checking outputs or state changes).

    I chose this resource because I wanted a clearer and more practical explanation of stubs beyond classroom slides. Sometimes lecture content feels abstract, and I was looking for something that connects theory to real-world software development practices. Martin Fowler is also a well-known expert in software engineering, so I felt his explanation would be reliable and insightful.

    From this resource, I learned why stubs are especially useful during early development stages. For example, if a class depends on a database or external API that is not ready, we can create a stub that mimics expected behavior. This allows testing to proceed without waiting for the full system. I also understood the difference between verifying outputs (state-based testing) versus verifying interactions like whether a method was called (behavior-based testing). This helped me connect stubs with other testing concepts like mocks.

    One important takeaway for me was how stubs improve productivity and support incremental development. Earlier, I used to think testing could only happen after everything was implemented. Now I realize that with stubs, testing can happen in parallel with development. This is especially useful in team environments where different members are working on different modules.

    I also found the idea of output capture interesting. By capturing console output or logs, we can verify whether the correct method in the stub was called. This gives a simple way to perform behavior-based testing without complex frameworks.

    Going forward, I plan to apply stubs in my own projects, especially in my capstone project where multiple components depend on each other. Instead of waiting for all modules to be complete, I can use stubs to simulate dependencies and continue testing early. This will help me write more reliable and maintainable code. Overall, this topic has changed how I think about testing. It is not just a final step, but something that can be integrated throughout the development process.

  • Sprint Retrospective – Dependency Management in NodeJS Backend

    During this sprint, our team focused on dependency management for a NodeJS backend system within the LibreFoodPantry project. My primary responsibility involved updating dependencies, fixing compatibility issues, and ensuring that the backend remained stable after changes. This sprint required both technical work and strong collaboration with teammates.

    Evidence of Activity

    What Worked Well

    One thing that worked well during this sprint was team collaboration. I received a lot of helpful feedback from my teammates, especially during merge request reviews. This helped me improve my code quality and understand best practices for dependency updates. Another positive aspect was breaking down dependency updates into smaller commits, which made debugging and tracking changes easier.

    What Didn’t Work Well

    Updating dependencies turned out to be more complex than expected. Some updates caused compatibility issues, especially with libraries like express-openapi-validator. Also, switching from Yarn to NPM required careful adjustments, and initially, it introduced some confusion in the build process. These issues slowed down progress.

    Improvements as a Team

    As a team, we could improve by planning dependency updates more strategically. Instead of updating everything at once, we should group updates and test incrementally. Better documentation of decisions (like switching package managers) would also help everyone stay aligned.

    Improvements as an Individual

    Individually, I could improve by researching dependencies more before upgrading them. Understanding breaking changes ahead of time would reduce trial-and-error debugging. I also want to get better at reading official documentation and changelogs more efficiently.

    Apprenticeship Pattern: “Use the Source”

    Summary:
    The “Use the Source” pattern encourages developers to rely on original documentation, source code, and primary references instead of guessing or relying only on others.

    Why I Selected This Pattern:
    I selected this pattern because dependency management heavily depends on understanding library behavior. During this sprint, I often relied on teammates for guidance instead of directly exploring documentation or source code.

    Relevance to My Experience:
    When updating packages like Express or MongoDB, I encountered issues that could have been solved faster by checking official docs or GitHub repositories. This pattern directly relates to those situations.

    How It Would Have Changed My Behavior:
    If I had applied this pattern more actively, I would have spent more time reading documentation before making changes. This would have reduced errors and made me more independent. It would also have helped me understand why certain fixes worked instead of just applying them.

    Conclusion

    Overall, this sprint was a valuable learning experience in dependency management and teamwork. While there were challenges, especially with compatibility issues, I gained practical experience in maintaining a NodeJS backend. Moving forward, I plan to improve both my technical skills and my ability to work more independently while still collaborating effectively with my team.

  • Boundary Value Analysis in Software Testing

    In my self-directed professional development this week, I explored the topic of Boundary Value Analysis (BVA) in software testing. We have discussed this topic under the tutelage of Professor Perez recently. The article I selected is titled “Boundary Value Analysis” from the QAble testing blog. The resource explains how testers can design effective test cases by focusing on input values that occur at the boundaries of acceptable ranges. The article can be accessed here:
    https://www.qable.io/blog/boundary-value-analysis

    The main idea presented in the article is that many software defects occur not in the middle of valid input ranges but at the extreme boundaries of those ranges. Boundary Value Analysis is therefore a testing technique that concentrates on validating the minimum, maximum, and values just inside and outside the boundaries of input constraints. For example, if a system accepts numbers between 1 and 100, the key test cases should include values like 0, 1, 2, 99, 100, and 101. By testing these edge cases, software testers can identify logical errors or validation mistakes that might otherwise remain undetected.

    I selected this particular resource because boundary testing is a fundamental concept in Software Quality Assurance, which is directly related to the course material. As someone studying computer science with a focus on software engineering, understanding systematic testing strategies is important for writing reliable and robust software. I wanted to better understand how professional testers design test cases efficiently instead of randomly trying input values.

    One thing that stood out to me while reading the article is how small variations near boundaries can expose serious system defects. For example, input validation errors might allow illegal values or incorrectly reject valid ones. This made me realize that testing is not just about checking whether software works in normal conditions, but also about identifying edge cases where systems may fail. The article also emphasized that Boundary Value Analysis is often used together with Equivalence Partitioning, which further improves the efficiency of test design. This connection helped me understand how multiple testing techniques can complement each other.

    Reflecting on this resource, I learned that effective testing requires both analytical thinking and structured methodologies. In many of my programming assignments, I usually test my programs with a few normal inputs just to confirm that the program runs correctly. However, after reading this article, I realized that I should also intentionally test boundary conditions. For example, when designing programs that accept user input such as age ranges, scores, or array sizes, I should verify the smallest allowed value, the largest allowed value, and values just outside those limits.

    In my future software development practice, I expect to apply Boundary Value Analysis when writing unit tests and validation logic. As a future software engineer, I believe this technique will help me produce more reliable software systems and reduce unexpected runtime errors. Overall, this article reinforced the importance of structured test design in improving software quality.

  • Sprint 1 Retrospective Blog Post

    The Software Dev Capstone Project related Theas Pantry has been very valuable to me as far as providing me with near real Software Engineering experience is concerned. I am part of ‘Dependency Management and infrastructure updates’ Team.  We started this project first by working on GuestInfoBackend Module. As part of my role, I have completed below tickets

    https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/commit/45db754a21c8e50ea05ac80a41233d797e0e1388

    Above is the link demonstrating my work of updating ‘winston’ package to latest version.  Secondly, I worked on updating the package ‘amqplib’ as well as illustrated by the below URL.

    https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/commit/a810da88d2f11508a7316c6bea61e80fbf717fdc

    We then moved to updating dependencies for the ‘Frontend’ System. As part of this Sprint, I worked on below tickets

    https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/986bcf7d9885d8e27e7c619e40f1c77a8c1134cd

    As part of the current work on ‘Reporting System’, I worked on updating dependencies related to ‘mongodb’, ‘mocha’ and ‘chai’.

    https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/commit/3dc96afa9fc27da3d541380efa10c77d0a08eb4f

    https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/commit/7dba17365f41ea870f909495e799b1049700d2f9

    https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/commit/1cd1be00b0788c2e9ff89043b1590e42064c5156

    What worked Well?

    We came together as a team and were fully aligned with our goals. We established communication channels using MS-Teams and were constantly working as a synergized team. We rarely had any misunderstandings or misgivings about each other and always assumed good intentions from each other’s work. We supported each other when we made mistakes and it was a thoroughly cherishable experience working with this team.

    What didn’t work well?

    I think our unfamiliarity with the technology stack consisting of NodeJS, java script and the whole art and science of dependency management threw many curve balls at us. We would have been more productive had we had previous knowledge of this technology stack. However, we overcome insurmountable odds and were able to honor the timelines that were provided to us.

    what changes could be made to improve as a team?

    The team has overcome the initial fear and lack of confidence very fast. The team is improving each week in terms of understanding the scope of work and the deliverables both from a technological and functional point of view. I do not think we have any compelling area that calls for radical improvement currently.

    What changes could be made to improve as an individual?

    I am basically an introvert and reserved by nature. I realized that such characteristics will not gel well with team-based Software engineering projects. I am inspired by the soft skills and confidence demonstrated by my teammates. I must improve my soft communication skills, articulate my thoughts better and be more vocal about my issues and deliverables.

    Apprenticeship Pattern

    Pattern Selected: Concrete Skills (from Apprenticeship Patterns by Dave Hoover and Adewale Oshineye)

    The Concrete Skills pattern emphasizes the importance of developing practical, hands-on technical abilities that can be directly applied in real software development environments. Rather than focusing only on theoretical knowledge, the pattern encourages software apprentices to deliberately practice specific skills such as programming, debugging, testing, and using development tools. By strengthening these tangible skills, a developer becomes more effective in contributing to team projects and solving real problems. The pattern also highlights that mastery in software engineering is built gradually through continuous practice and improvement of these concrete abilities.

    I selected this pattern because it strongly relates to my experience during the spring sprint in this course. As a senior computer science student, I noticed that many tasks during the sprint required applying specific technical skills rather than only conceptual understanding. For example, working with version control systems, debugging code, and collaborating with teammates required practical knowledge that comes from hands-on experience. The pattern resonated with me because it reinforces the importance of actively strengthening these core technical competencies.

    If I had read this pattern before the sprint, it likely would have influenced my preparation and approach. I would have spent more time practicing the relevant tools and technologies beforehand, particularly debugging techniques and collaborative development workflows. This preparation could have helped me work more efficiently and contribute more confidently to the team throughout the sprint.

  • Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions

    I thoroughly enjoyed reading the textbook “Apprenticeship Patterns”. I wish I had read it much earlier in life. It is very inspiring and inculcates enormous wisdom to young aspiring professionals across all trades but more particularly in Software Domain.

    I found it very interesting that the book discourages aspiring Software development practitioners to discard the path of aspiring to become middle managers or C-Suite honchos. It states in very clear terms that becoming managers would mean that we become armchair experts and lose the grip on ground realities soon. It emphasizes the fact that we should focus on becoming better in a consistent manner in our Software development craft without being greedy about material gains or false perspective on what conventional society considers as success. For e.g… Society considers a Senior Vice President or CIO more successful than a dedicated Staff Engineer. But the Staff Engineer has dedicated their life to becoming good at what they started in their youth and get a sense of fulfillment from their work.

    The reading has caused me to change my opinion. I now learnt that I should always strive to be in teams where I am the poorest or weak aptitude wise. This gives me opportunity to learn from professionals who are much better than me and gain from their enormous experience. Before reading this book, I aspired to find jobs that would provide me with a comfort zone. I cherished reading the quote by C.S. Lewis in “Learning in Wartime” in this book. The quote states that “The only people who achieve much are those who want knowledge so badly that they seek it while the conditions are still unfavorable. Favorable conditions never come”. This is a very inspiring quote that compels us to get into the grind without waiting for perfect weather.

    So far, I have not found anything that I disagree with in this book. However, I would be curious to know the author’s perspective on this topic in this age of Generative AI. How should Software Interns and apprentices hone their craft with the advent of Large Language models. This especially considers so many predictions in recent times that this entire skill and the demand for it will soon die down. Agentic AI will replace Software Engineers. I would still assume Software Engineers may be needed to provide human oversight. However, time will tell on this subject.

    I think all chapters are important and align well with the over-arching topic. I am going to read and read this book several times during my lifetime. I am grateful for this opportunity.

  • Getting Started with JUnit: Testing in Java

    As part of our course material on software quality and testing, I chose to read the blog post “Getting Started with JUnit Testing: The Path to Effective Java Automation” https://www.frugaltesting.com/blog/getting-started-with-junit-testing-the-path-to-effective-java-automation published on Frugal Testing. This resource directly relates to what we have been learning about unit testing and test-driven development, especially in Java-based applications. Since JUnit is one of the most widely used testing frameworks in Java, understanding its fundamentals is essential for any computer science student who plans to work in software development.

    The blog post provides a clear and structured introduction to JUnit, explaining what unit testing is, why it matters, and how JUnit supports automated testing in Java projects. It walks through key concepts such as test cases, assertions, annotations like @Test, and the general workflow of writing and executing tests. The author also emphasizes how automated unit tests help catch bugs early, improve code reliability, and support refactoring. Overall, the article serves as a practical starting point for developers who are new to testing or want to strengthen their testing practices.

    I selected this particular resource because I wanted a beginner-friendly yet practical explanation of JUnit that connects theory with real-world usage. While we often hear about the importance of testing in class, it can be difficult to visualize how testing fits into everyday development. This blog stood out because it focuses on hands-on testing concepts rather than abstract definitions, making it easier to connect course topics to actual coding practice.

    One of the most important things I learned from this article is how unit testing is not just about finding bugs, but about improving the overall design and maintainability of code. Writing tests forces developers to think more carefully about how their code is structured and how different components interact. The explanation of assertions helped me better understand how tests validate expected behavior, and the overview of JUnit annotations clarified how test execution is managed behind the scenes.

    This resource changed how I think about testing in my own projects. Previously, I viewed testing as something optional or done at the end of development. After reading this article, I see testing as an integral part of the development process. In the future, I expect to apply what I learned by writing JUnit tests alongside my Java code, especially for assignments and personal projects. This approach will help me catch errors earlier, write cleaner code, and build confidence in my software.

    Resource Link:

    https://www.frugaltesting.com/blog/getting-started-with-junit-testing-the-path-to-effective-java-automation

  • Introductory Blog Post for CS-443-01

    Hello, my name is Vishisht Seku. This is my Blog Post related to subject CS-443(Software Quality Assurance & Testing.) I am very glad to be a part of this class and learn more about the process of Software Quality Management.

  • Introductory Post on LibreFoodPantry and Thea’s Pantry

    One part of LibreFoodPantry that I found especially interesting was its mission to connect computer science education with real humanitarian impact. Rather than treating software development as an abstract or purely technical exercise, LibreFoodPantry shows how code can directly support local food pantries and the people who rely on them. The idea that free and open-source software can be adapted to meet the needs of different communities stood out to me, because it emphasizes flexibility, accessibility, and long-term usefulness instead of profit.

    I chose to write about this mission because it reframes how I think about computing as a field. As a senior at Worcester State University, much of my coursework has focused on efficiency, correctness, and performance. While those skills are important, LibreFoodPantry highlights another dimension of computer science: responsibility to society. By involving students and faculty in instructor-led, open-source projects, the organization creates a learning environment where technical skills are developed alongside empathy and civic awareness. This approach makes the work feel meaningful and shows that software can be a practical tool for social good, not just a career skill or academic requirement.

    The one thing that I thoroughly enjoyed reading about Thea’s Pantry was the Developer Documentation section. As an aspiring Software and Data Engineer this documentation was a revelation and a textbook. I liked the sections around ‘Code of Conduct’ and ‘Inclusive Language’ a lot. They inspire us to take a moral high ground and be kind and compassionate to our team members.

    I also enjoyed the technical sections that gave me a good grasp on managing Workflows using the Git Branch, Pull Request protocol. Other sections such as ‘Release Process’ and ‘Pipelines’ provide a rigid framework around the intended CI/CD Process. Regarding ‘Dependency Management’ I was surprised to find differences between ‘Dependencies’, ‘Dev Dependencies’ and ‘Peer Dependencies’. So far, I only assumed we need to manage ‘Dependencies’ as a single unit.

    I am very glad to be part of this Capstone Project with a noble mission.

  • Designing RESTful APIs for Microservices Architecture

    The recent work assigned to us regarding REST API services has been very enlightening to me. I have found that REST API’s form the heart of Microservice architecture as well. REST API’s help Software Engineering Teams to break monolith Software application code into modular, atomic and maintainable code services. To explore this further, I read a blog post titled “Designing RESTful APIs for Microservices Architecture” https://blog.xapihub.io/2024/04/17/Designing-RESTful-APIs-for-Microservices-Architecture.html from XapiHub. This post explains how REST API design plays a critical role in making microservices effective, reliable, and loosely coupled. Since we are learning how clean design and good processes improve software quality, I felt this resource fit directly into our course themes.

    The blog begins by explaining that microservices rely heavily on APIs to communicate with each other. REST is the most common choice because it is simple, stateless, and works well across different services and technologies. The author highlights several best practices such as using clear resource-based URLs, handling errors consistently, applying versioning to avoid breaking clients, and building truly independent services that do not secretly depend on each other’s data models. The blog also emphasizes monitoring, documentation, and strong authentication practices, which are especially important when many services are talking to each other across the network.

    I selected this resource because I found it very simple with lot of simple to understand diagrams and easier to understand language. I have always found microservices interesting but a little overwhelming. When people talk about dozens or hundreds of services communicating through REST, I sometimes imagine chaos. This blog made the topic feel more understandable by breaking it into practical design rules. Since our class focuses on professional processes, documentation, and maintainability, learning how microservices stay organized through REST guidelines felt very relevant. Also, I know many modern data-engineering and enterprise systems use microservices—exactly the direction I want to grow my career in.

    One of the biggest things I learned is how important statelessness is. I always assumed microservices were powerful mainly because of their independence, but I didn’t realize how much stateful communication can ruin scalability. Another takeaway was API versioning. Before this, I didn’t think deeply about how older clients might break when an API changes. The blog’s explanation helped me understand why backward compatibility is a core part of good software process management.

    It appears that the path ahead to be a successful Software Engineer is overwhelming with so much to comprehend and implement. We have to be good not just at programming languages but also such principles of effective Application Engineering. This blog helped me connect industry best practices to what we’ve been learning in class about writing clean, maintainable, and well-designed software systems.

  • Clean Code Practices in Java

    I am thoroughly enjoying the classes on writing clean code under the aegis of Professor Al-Faris in Software Process Management course. While looking for more material outside class, I found a blog post titled “How to Write Clean Java Code: Best Practices” on Digma’s website https://digma.ai/clean-code-java/. Since we work a lot with Java especially in our design patterns (Software Construction Design and Architecture under Professor Wurst) and project classes—I felt this blog would be perfect to learn some practical ideas on writing cleaner code. It directly connects to the course concepts of good processes, readability, and long-term maintainability.

    Summary of the Blog Post

    The blog highlights several clean-code principles specifically focusing on Java. It talks about using meaningful names, keeping methods small, breaking down complex logic, and making classes more focused on single responsibilities. It also covers organizing projects so that packages and modules make sense. Other topics include avoiding unnecessary comments, choosing good formatting, and using tools like linters and static analysis to keep code quality consistent across a team. The blog also mentions the importance of avoiding side effects and making code more predictable so that debugging becomes easier.

    Why I Picked This Resource

    I picked this blog mainly because I sometimes struggle with writing code that is easy for other people to read. In group projects, especially in CS-343 and other classes, I’ve noticed that even when my code works, people ask me to rewrite parts to make it more understandable. Since the course emphasizes professional development and communication skills, I wanted to learn more about how to write code that doesn’t confuse future developers—including a future version of myself. Also, I’m working with Java in my Android and backend mini projects, so the resource felt immediately relevant.

    What I Learned and My Reflections

    One thing that really affected me was the section on method size and single responsibility. I realized I often cram too much logic into one method because it feels “efficient” while writing it. But the blog explains that smaller, focused methods improve readability and make testing easier. Another important point was naming. I always knew naming mattered, but the blog explained it in a more practical way—names should communicate intent, not just function.

    I also learned about using automated tools to maintain code quality. Honestly, I never used static analyzers or formatters seriously, but now I see how they support good software processes, which we discuss a lot in this class. Clean code isn’t just a personal style; it’s part of a team’s workflow and long-term sustainability.

    How I Will Apply This Going Forward

    Going forward, I plan to be more disciplined about breaking up my functions, using stronger naming, and removing unnecessary comments. I also want to integrate automated formatting and code-quality tools in my personal projects, so I get used to writing cleaner code consistently.