-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC]: Develop a project test runner. #53
Comments
Dear @kgryte, @Planeshifter, and @Pranavchiku, I kindly request your review of this at your earliest convenience. Your valuable feedback would be greatly appreciated. Thank you. |
@vr-varad Thanks for filing this draft proposal. A few comments:
|
"Refactor existing tests for improved readability" involves restructuring the test suite to enhance clarity and maintainability. I'll prioritize critical tests and gradually refactor them, preserving functionality. While I aim not to make any changes, I'll consult maintainers if any such situation arises. Given the project's scale, I'll assess feasibility and prioritize tasks, considering impact and resources, to ensure efficient execution. |
For running tests simultaneously, I suggest starting with a per-file approach. This means tests in the same file can run together, which can speed things up without making it too complicated. But I'm open to other ideas if needed, depending on how the project works and how fast we need tests to run. |
@kgryte, I've implemented the suggested changes and addressed your inquiries in the proposal. Please review it at your convenience. Let me know if there's anything else you need or if you encounter any issues. |
@kgryte @Pranavchiku Any more suggestions or changes I could make to improve my proposal. |
Hi @vr-varad, thanks for sharing your draft proposal! I still have some of the questions that @kgryte mentioned in his previous comment, specially because you are naming a lot of "refactoring" tasks without being specific as for what changes are going to be made and to what packages. I also have these questions,
|
Building on Stephannie's comments,
In general, it would be good if you can flesh out your proposed tasks to make things more concrete. |
Certainly, let me address those questions:
|
Certainly, let's address each of these questions:
|
@vr-varad Please refrain from replying with LLM generated answers. |
@kgryte Sorry but I have my notes and I am using LLM to frame sentences |
Sorry for that but not any answer is LLM generated its all framed sentences from my notes. |
Understood. While we recognize that LLMs will continue to play a greater role in development, it is important that we hear your voice. In this particular case, LLM inspired answers did not answer our questions, especially as to how, e.g., "Matchers" applied to stdlib and why these had their own dedicated weeks (Weeks 10-11), especially when the set of assertions we use throughout stdlib is relatively limited (e.g., In short, leverage LLMs, but do so in a way which enhances your understanding. If we wanted LLM answers, we could have just used an LLM ourselves. Your task is to demonstrate that we should select you over an LLM. |
@kgryte I could understand what are u saying, i should not be using it to answer the questions but to take help from that espicially in the case of these projects. |
In general, I am against implementing matchers in the test runner. That is simply not a convention we use, and we're not planning on migrating. This test runner should target specifically how we write tests. There may be some innovation, but this is not an area where we're interested in innovating. As an example of where we are interested in innovating is in supporting something like t.throws( foo( value ), 'throws a %s when provided %s', 'TypeError', JSON.stringify( value ) ); Notice the support of string interpolation. Compare that to how we currently write similar tests in the project. |
In that case, I could shift from implementing matchers to adding some implementation like this
as it's heavily used in the module which could have third parameter as optional and default as "'returns expected value" |
|
Nope. :) Also not something we do in the project and, again, would entail a significant refactoring. Since you are seeking other innovations, another would be |
In that case, I could shift from implementing matchers to adding some implementation like this
as it's heavily used in the module which could have a third parameter as optional and default as "'returns expected value"
to
something like that(or not checking type). |
@kgryte I could work on these methods (I would be updating the above list) |
Not sure why you'd need to create a separate website. We already have API docs published on the project website. |
No on |
@kgryte In the proposal I have added few new task
|
@kgryte Any suggestions or corrections?? |
|
adding {skip: true} would be part of tagging test. |
apart from all the above the things that we could done is
|
Beyond the scope for this project. |
@kgryte I have made the changes in the proposal and am about to submit it. |
No. You should be good to submit. Good luck! |
@kgryte @steff456 @Planeshifter @Pranavchiku |
Full name
Varad Gupta
University status
Yes
University name
Indian Institute of Information Technology, Ranchi
University program
Btech in Computer Science and Technolody with spez in AI and DS
Expected graduation
2026
Short biography
🚀 Hi, I'm Varad, a Full Stack Developer specializing in backend development, currently studying computer science at IIIT Ranchi with a focus on AI and DS. My expertise lies in crafting robust solutions using the MERN stack—MongoDB, Express.js, React, and Node.js. Additionally, I'm able to work proficiently in Python and passionate about integrating AI into projects.
⚙️ I'm well-versed in backend technologies like Docker and Kubernetes for scalability, and I have experience working with GraphQL for efficient data management.
💡 I'm excited about the opportunity to collaborate and create innovative solutions that push the boundaries of technology.
Timezone
India Standard Time, Time zone in India (GMT+5:30)
Contact details
[email protected]
Platform
Linux
Editor
🚀 Visual Studio Code (VS Code) stands out as my editor of choice for its seamless blend of functionality and efficiency. With its sleek interface and robust features, it enhances my workflow as a Full Stack Developer specializing in backend development. From its support for the MERN stack to seamless integration with Git, VS Code streamlines coding and collaboration. Its extensive debugging capabilities ensure swift issue resolution, while its customizable nature allows for tailored development environments. In essence, VS Code's versatility and performance make it an invaluable tool for navigating the complexities of modern software development with precision and ease.
Programming experience
🚀 My coding journey began with HTML and Python, evolving through C and C++, until I immersed myself in the dynamic world of the MERN stack—MongoDB, Express.js, React, and Node.js. It was within backend development that I found my true passion, sculpting scalable solutions and dynamic APIs with Node.js as my cornerstone. Through challenges and triumphs, my commitment to backend craftsmanship only deepened. Now armed with a wealth of experience and an unwavering love for backend intricacies, I'm poised to navigate the ever-evolving tech landscape with confidence and innovation, driven by a relentless pursuit of excellence.
Project Highlights:
Twitter Backend System: A robust architecture supporting tweet posting, image uploads, likes, comments, and hashtags. Efficiently managing user profiles, authentication, and engagement features, it ensures a seamless and secure experience for a dynamic social media platform.
Airplane Booking System: Leveraging MongoDB, Express, and Node.js for data management. Robust authentication secures flight and passenger data, ensuring optimal performance and scalability.
JavaScript experience
🚀 My journey with JavaScript encompasses mastering foundational concepts like arrays and functions, advancing to topics such as coercion, OOP, and async programming. From creating simple games like chess to building backend applications, JavaScript's versatility has been my canvas. Crafting games has honed my problem-solving skills, while backend development with Node.js and Express.js has enabled me to build RESTful APIs and real-time applications seamlessly. Transitioning between frontend and backend, I've relished the challenge of architecting scalable solutions. JavaScript's power in both realms continues to inspire me, pushing the boundaries of what's achievable in programming.
Node.js experience
🚀 Embarking on my Node.js journey, I've witnessed its evolution from a server-side runtime to a cornerstone of modern backend development. With Node.js, I've mastered the art of crafting robust, scalable applications, seamlessly integrating with frontend technologies to deliver captivating user experiences. Asynchronous programming challenges have become exhilarating opportunities for optimization, while building RESTful APIs and real-time applications has honed my skills in architecting elegant solutions with frameworks like Express.js. From small-scale projects to enterprise-level systems, Node.js has consistently fueled my passion for pushing the boundaries of backend development. Its versatility, performance, and reliability inspire me as I navigate the dynamic landscape of technology.
C/Fortran experience
🚀 Starting with limited experience in C, I delved into basic data structures like arrays and strings, gradually mastering intricate ones such as linked lists, trees, and graphs. Proficient in dynamic memory allocation, I've engineered efficient solutions, navigating data manipulation and optimization challenges with precision.
Interest in stdlib
I'm intrigued by stdlib's vision to transform numerical computation online. Its unique combination of JavaScript and C, along with a modular structure, resonates well with my expertise. I'm impressed by its dedication to quality, reflected in meticulous testing and detailed documentation. With stdlib, I envision a future where complex computations are simple and accessible to everyone. Joining this community means shaping that future together.
Version control
Yes
Contributions to stdlib
PR Merged: https://github.com/stdlib-js/stdlib/pulls?q=is%3Apr+vr-varad+is%3Amerged
PR Open: https://github.com/stdlib-js/stdlib/pulls?q=is%3Apr+vr-varad+is%3Aopen
Issue currently working on: stdlib-js/stdlib#1517
Goals
Develop an in-house test runner for stdlib, optimizing testing efficiency to stdlib/bench/harness standards. This migration from tape streamlines testing, ensuring uniformity across unit tests and enhancing overall integrity.
Testing Approach:
Unit testing isolates code units for rigorous examination. A robust test runner, akin to stdlib/bench/harness, manages test suite loading, unit execution, result recording, and report generation, ensuring comprehensive coverage.
Advantages:
Unit testing accelerates test runs, bolsters test independence, and elevates consistency in outcomes. By targeting specific code units, developers fortify code reliability and maintainability.
Implementation:
The in-house test runner handles test suite and unit loading meticulously, aligning closely with stdlib/bench/harness standards. This approach optimizes testing environments, seamlessly integrating with stdlib's practices, and enhancing the testing landscape for future development.
Why this project?
Expertise Alignment: This project resonates with my proficiency in JavaScript, including Node.js, and C, providing an avenue to apply my skills effectively.
Challenge and Innovation: Migrating from tape to a custom test runner, particularly in a Node.js environment, presents a stimulating technical challenge, driving innovation in testing frameworks.
Impactful Contribution: Active involvement in this project allows me to significantly enhance stdlib's testing processes, promoting standardized practices within the developer community, especially in Node.js development circles.
Professional Development: Engaging in this project facilitates my growth as a software engineer, offering valuable experience in project management, collaboration, and problem-solving, particularly within the Node.js ecosystem.
In summary, selecting this project aligns with my expertise and aspirations, offering a compelling opportunity for impactful contributions and professional advancement in the realm of Node.js development and beyond.
Qualifications
In executing this proposal, I possess the technical acumen requisite for developing an in-house test runner for stdlib. Proficient in JavaScript, encompassing Node.js, and C, I navigate testing frameworks with fluency. My adept project management skills ensure agile delivery, while my astute problem-solving aptitude enables effective resolution of technical intricacies. Despite lacking formal qualifications in testing methodologies or statistics, my dedication to continual learning and adaptability equip me to contribute meaningfully to the project's success. In summary, my technical prowess, project management acumen, and problem-solving proficiency render me well-suited to propel the project forward and achieve exemplary outcomes.
Prior art
Before initiating the development of a custom test runner for stdlib, it is prudent to explore prior endeavors in the software development domain. Various projects have already pursued similar objectives, either by creating their own test runners or adopting alternative testing frameworks. For instance, notable examples such as Jest in the JavaScript ecosystem exemplify how custom test runners can streamline testing processes. Moreover, scholarly articles, blog posts, and community forums serve as repositories of valuable insights and best practices. By studying these resources, we can glean pertinent information to inform the design and implementation of the stdlib test runner, ensuring its efficacy and alignment with established industry standards.
Commitment
I am fully committed to dedicating 45-50 hours per week to the project before, during, and after the Google Summer of Code program. With unwavering dedication and focus, I will prioritize project milestones and deliverables to ensure its successful completion. I do not have any conflicting commitments such as vacations, other jobs, or exams that would impede my ability to fully devote myself to the project during the program period. This commitment extends beyond the program duration, as I am eager to continue contributing to the project's success in the long term.
Schedule
Assuming a 12 week schedule,
Community Bonding Period:
Set up local development environment with required tools such as Node.js and Git.
Study existing folder structure and codebase to understand the project architecture.
Discuss and refine project goals and requirements with mentors.
Research and plan folder structure improvements for better organization.
Week 1:
Initialize NPM project and install dependencies.
Configure project settings in package.json.
Develop core test runner entrypoint for test execution and reporting.
Week 2:
Ensure package availability and local linking.
Integrate test runner with a sample application.
Implement error handling mechanisms for accurate test reporting.
Week 3:
Enhance test runner for parallel test execution.
Validate functionality with complex test scenarios.
Week 4:
Implement 't' function for defining test cases.
Define standard test assertions for descriptive test names. (equal, deep-equal, end, pass, skip, ok, set-timeout, clear-timeout, exit, run. not-equal, not-deep-equal, not-ok, etc)
Week 5:
Develop mechanisms for managing test contexts.
Organize and describe test cases using 't' and nested 'test' blocks.
Implement error handling for exceptions.
Week 6: (midterm)
Integrate CI/CD pipelines for automated testing.
Enhance test output formatting and error reporting.
Support nested 'test' blocks for modular organization.
Week 7:
Implement hooks for setup and teardown.
Update sample application for framework enhancements.
Discovering testing files.
Week 8:
Supporting Asynchronous Tests
Week 9:
Handle multiple failures per test.
Test the solution for clarity and correctness.
Week 10:
Test Tagging.
Skipping Tests.
Week 11:
Refactoring test assertion methods and optimizing them.
Week 12:
Integrate formatter with the Runner.
Final Week:
Explore development workflows and test runners.
Notes:
Sample Test Runner Would look like.
Related issues
No response
Checklist
[RFC]:
and succinctly describes your proposal.The text was updated successfully, but these errors were encountered: