Pratik772846
commented
3 months ago Hey @kgryte ,@Pranavchiku ,@Planeshifter , can you please provide any suggestions on this?
Closed Pratik772846 closed 2 months ago
Pratik772846
commented
3 months ago Hey @kgryte ,@Pranavchiku ,@Planeshifter , can you please provide any suggestions on this?
Pranavchiku
commented
3 months ago @Pratik772846 can you brief more about files in runner and test-class, and if you can get this thing running with a small package that will be cherry on top. Your outlined plan looks good. Thanks!
Pratik772846
commented
3 months ago Hey @Pranavchiku , I have made the necessary changes , kindly review it at your convenience.
kgryte
commented
3 months ago Thanks, @Pratik772846, for sharing a draft of your proposal. A few comments:
istanbul to c8: https://github.com/stdlib-js/stdlib/blob/3080f032a477cbd046b4201d7ffdd407c9d93816/package.json#L128equal and strictEqual. These are actually aliases of each other in tape. Our preference moving forward is to just have a single equal method.tape in order to include a patch we needed for use in stdlib. tape development has continued in the meantime. Is there anything in the latest tape that we should consider when developing our in-house test runner?require statements. We'd also like to simplify things further when writing tests in the project. (1) Having default test messages. E.g., we use "returns expected value" throughout the project. It would be good to make that a default, so as to save keystrokes when writing tests. We've tried to standardize but this is still a WIP. Furthermore, it would be good to have assertions for approximate equality. Lastly, we'd like to be able to use @stdlib/string/format for simplifying test message construction, which relies heavily atm on string concatenation. In short, there are various DX improvements we'd like to make when creating the test runner.Pratik772846
commented
3 months ago Thanks for your suggestions @kgryte , I have incorporated the suggested changes in my proposal.
Regarding 2nd point : I will handle tests sequentially. After every test completes its execution, including any asynchronous operations and cleanup logic, the test runner will proceed to execute the next test. The test execution flow will be event-driven, where several events such as 'run' and 'end' will be emitted by the test runner. These events will be handled sequentially, ensuring that the tests are executed in order.
I am also open to any type of suggestions regarding handling the tests parallelly and would be happy to discuss them with mentors.
Regarding 3rd point: I will find similar assertion methods like equal and strictEqual which are aliases of each other. Tape also has the same implementation for both of them. So, I will find all these kinds of assertion methods and go with only a single alias.
Regarding the 4th point: I am researching over this thing and will include in my proposal . Regarding the 5th point: I will remove messages from assertion methods like equal and wherever required and keep them default. Like In the case of “deepEqual”, the default message can be “returns expected value”. Similarly, In the case of “ok”, the default message can be “returns truthy value”.
I will also add some new methods like “almostEqual” ( this method will be for floating point numbers, we will check whether both numbers lie within a specified tolerance or not ). Also, we can add methods like complexEqual ( for directly comparing complex numbers ). I will decide upon these methods after discussion with the mentors during the community bonding period. Also, Based on your suggestion wherever string concatenation is required, we can use @stdlib/string/format. Similarly, I will identify these kinds of things and will replace them with our in-house packages
Pratik772846
commented
3 months ago Also right now in most of the cases, we are only using "equal/strictEqual", "deepEqual", "ok", "throws", "pass", "fail", and "end" assertion methods. These assertion methods are quite common among all the packages. Besides this, from your suggestion, I plan to include assertion methods for floating point numbers and a few more if needed.
kgryte
commented
3 months ago It would be good to get rid of the equal/strictEqual equivalence and just have equal. We don't need both.
Pratik772846
commented
3 months ago It would be good to get rid of the
equal/strictEqualequivalence and just haveequal. We don't need both.
Yes, I will include only "equal" in the test runner.
Pratik772846
commented
3 months ago Also, for "deepEqual" in @stdlib/bench/harness implementation has not been done.
Can I go forward and implement it?
kgryte
commented
3 months ago I'm not sure we actually need to implement it, TBH. We have @stdlib/assert/deep-equal, and I'm not convinced we need to add it to the benchmark harness at this point. I can think of zero benchmarks in which we've needed to test for deep equality.
Pratik772846
commented
3 months ago I'm not sure we actually need to implement it, TBH. We have
@stdlib/assert/deep-equal, and I'm not convinced we need to add it to the benchmark harness at this point. I can think of zero benchmarks in which we've needed to test for deep equality.
Ok @kgryte. I will submit my proposal on GSOC website now. Thanks for your guidance and suggestions so far. Also, the length of this project is mentioned as 175/350 hours. On the GSOC website should I select medium as project size?
kgryte
commented
3 months ago I think it is fine to use 350 hours, taking into account the availability you mention in your draft proposal above. There will be plenty of things to do. :)
Full name
Pratik Kumar
University status
Yes
University name
Indian Institute of Information Tehcnology design and manufacturing Jabalpur
University program
BTECH in Computer Science and Engineering
Expected graduation
31/07/2025
Short biography
My name is Pratik Kumar, and I'm currently a pre-final year Computer Science and Engineering student at IIIT Jabalpur. Over the past two years, I've been deeply immersed in JavaScript and Node.js, exploring their associated technologies and frameworks. My journey with these technologies has been further enriched through practical experiences, including a two-month internship and successfully completing a freelance project.
During my internship, I had the opportunity to delve into new concepts and technologies, which broadened my understanding and expertise in JavaScript and Node.js. This experience, coupled with my freelance project, allowed me to solidify my skills in these areas.
Throughout my journey, I've focused on understanding object-oriented programming principles, which have complemented my strong grasp of JavaScript and Node.js. My active participation on coding platforms like LeetCode and Codeforces has helped me sharpen my proficiency in data structures and algorithms, further enhancing my capabilities.
Recently, I've been contributing to STDLIB, where I've been exploring its extensive codebase and actively engaging in development tasks. This experience has provided me with invaluable insights and has significantly contributed to my skill set.
Overall, my experiences with JavaScript and Node.js have equipped me with a strong foundation and practical expertise, making me confident in my abilities to tackle any project in these domains.
Timezone
Indian Standard Time ( IST ) , (GMT+ 5:30)
Contact details
Email : singhpratik015@gmail.com / 21bcs164@iiitdmj.ac.in , Phone number : 6204636425 , Linkedin: https://www.linkedin.com/in/pratik-singh-828a36217/ , Github : https://github.com/Pratik772846/
Platform
Linux
Editor
I primarily use Ubuntu as my operating system, and my preferred editor is Visual Studio Code (VS Code). I find VS Code to be highly versatile, user-friendly, and feature-rich. Its extensive library of extensions and plugins allows for seamless integration with various programming languages, frameworks, and tools. Additionally, VS Code offers robust debugging capabilities, built-in Git support, and a customizable user interface, making it an ideal choice for my coding needs. Overall, the combination of Ubuntu and VS Code provides me with a productive and efficient development environment.
Programming experience
Over the past two years, I've gained extensive experience working with JavaScript, C, C++, and Node.js. I possess a deep understanding of these languages and their associated libraries and frameworks. I've completed two notable projects during this time.
The first project, Travel Advisor, serves as a comprehensive travel planning tool. It offers users a centralized platform to access essential details such as available hotels, hospitals, tourist attractions, and more for their desired destination. To accomplish this, I implemented web scraping techniques and integrated various public APIs.
The second project, EventWizard , functions as an event management platform. Users can create and manage events seamlessly, handling tasks such as guest invitations and budget tracking efficiently.
These projects showcase my proficiency in software development and highlight my ability to leverage multiple programming languages and technologies to create practical solutions.
JavaScript experience
My experience with JavaScript spans two years, during which I've gained a comprehensive understanding of the language's syntax, features, and best practices. I've worked on various projects, ranging from web development to server-side scripting using Node.js. With JavaScript, I've developed dynamic and interactive web applications, implemented client-side functionalities, and integrated with backend services through APIs. Additionally, I'm proficient in using popular JavaScript frameworks and libraries such as React.js and Express.js to build scalable and efficient applications.
My favorite feature of JavaScript is its flexibility and dynamic nature, which allows for rapid prototyping and versatile development. JavaScript's ability to be used for both client-side and server-side development, as well as its support for asynchronous programming with features like Promises and async/await, make it a powerful language for building modern web applications. Additionally, JavaScript's extensive ecosystem of libraries and frameworks, such as React, Angular, and Node.js, provides developers with a wide range of tools to tackle various challenges.
My least favorite feature of JavaScript is its loose typing and potential for unexpected behavior due to type coercion. While dynamic typing can be advantageous in certain scenarios, it can also lead to bugs and errors that are difficult to catch during development. Additionally, JavaScript's prototypal inheritance model and scoping rules can be confusing for newcomers and may require careful consideration to avoid pitfalls.
Node.js experience
Over the past two years, I've been deeply involved with Node.js, a powerful platform for building web applications. During this time, I've explored its many features and also learned about Express, a popular framework for Node.js. Using Node.js, I've created the backends for important projects like Travel Advisor and Event Management. These projects have helped me sharpen my skills in backend development and solve real-world problems effectively. Additionally, I'm experienced in writing unit tests using Jest, which ensures that my code works reliably. Overall, my experience with Node.js has been exciting and rewarding, giving me a strong foundation in backend development for web applications.
C/Fortran experience
In terms of C and C++ programming, I've accumulated a good amount of experience over the last two years during my college studies. I have a solid grasp of data structures and algorithms in these languages, along with a good understanding of object-oriented programming principles. This experience has enabled me to work on various projects and assignments where I've implemented algorithms, data structures, and system-level functionalities using C. Overall, my experience with the C programming language reflects a comprehensive understanding and practical application of its concepts, making me proficient in leveraging C for a wide range of programming tasks and projects.
Regarding Fortran, although I haven't worked extensively with the language, I possess a foundational understanding gained through self-study. I'm familiar with Fortran's syntax, data types, and basic programming constructs. While I may not have hands-on experience with Fortran in practical projects, I'm confident in my ability to quickly adapt and learn new languages and technologies based on my existing programming knowledge and experience.
Interest in stdlib
What captivates me about Stdlib is its vast array of utility functions and modules that cater to diverse needs within the Node.js ecosystem. From mathematical and statistical computations to file system operations and networking tasks, Stdlib offers a rich toolkit that proves invaluable for developers across a wide spectrum of projects.
Furthermore, Stdlib's unwavering dedication to excellence, performance, and adherence to industry standards is truly admirable. Its widespread recognition and adoption within the Node.js community underscore its status as a reliable foundation for countless applications and packages.
Version control
Yes
Contributions to stdlib
Merged PR’s Pull request for these 3 packages have been merged.
string/to-well-formed -> added support for replacing lone surrogates in a provided string in order to create a string which is "well-formed".
utils/none-own-by -> added a utility to test whether every "own" property of a provided object does not satisfy a predicate function.
array/base/with -> added the functional equivalent of Array.prototype.with()
Open PR’s
blax/ext/base/snansumors -> Updated to follow current project conventions.Basically migrated from C++ add-on interfaces to C add-on interfaces and then made various style and simplification changes.
Goals
The project aims to migrate away from using Tape and develop an in-house test runner tailored to the conventions and requirements of stdlib, a widely used library in the Node.js ecosystem. The proposed test runner will be designed to integrate seamlessly with stdlib's development workflow and coding conventions. It will offer simplicity and flexibility while catering to the unique requirements of the library, ensuring efficient and effective testing of its functionalities. Unlike other test runners, this in-house solution will avoid unnecessary features or dependencies, adhering closely to stdlib's established practices. Also, I will incorporate things like removing messages from some assertion methods adding default messages, and adding some new types of methods like comparing complex numbers and floating point numbers which tape does not provide at this moment. These things will surely improve the developer experience
Why this project?
What excites me most about this project is the opportunity it presents to make a substantial impact within the organization and the broader Node.js ecosystem. Developing a custom test runner tailored specifically for stdlib's needs is a unique challenge that aligns perfectly with my interests and skills in software development and testing. The prospect of elevating stdlib's testing capabilities significantly through this initiative is particularly motivating.
Moreover, this project offers an invaluable chance to go deeper into testing methodologies, tooling, and industry best practices in software development. By working on crafting and deploying testing frameworks, as well as navigating the details of code coverage analysis, I can expand my expertise and contribute meaningfully to the project's success.
I chose this project because it aligns with my goal of engaging in initiatives with direct implications for all other packages, which grants a competitive edge in terms of experience. The opportunity to migrate away from Tape and implement a more efficient testing solution not only enhances the overall development experience for stdlib contributors and maintainers but also presents a chance to contribute to the continued success and evolution of a vital open-source library.
Qualifications
With a solid understanding of JavaScript, Node.js, and Object-Oriented Programming, I am well-equipped to tackle the challenges presented by this project. Having tackled over 500 problems on platforms like Codeforces and LeetCode, I have honed my skills in Data Structures and Algorithms, enabling me to write optimized and efficient code. My previous experience as a software intern, where I led a team of four individuals on a collaborative project, and as a project lead for our Institute's open-source initiative, Project Fusion, has further strengthened my ability to work effectively within a team. Additionally, my contributions to STDLIB have provided me with valuable experience and familiarity with the codebase, positioning me as a valuable asset to this project.
Prior art
We currently utilize tape for our testing purposes, and within STDLIB, a similar tool named @stdlib/bench/harness already exists. Drawing inspiration from both of these existing implementations, I aim to develop our test runner accordingly.
Commitment
1 May - 26 May -> Bonding Period 27 May - 7 July -> 40 hours/week ( 40 6 ) 8 July - 17 August -> 20 hours/week ( 20 6 ) Total = 240 + 120 = 340 hours Apart from this, I have no additional commitments during the coding period.
Schedule
Assuming a 12-week schedule,
Community Bonding Period: Throughout this period, I plan to focus on establishing a comprehensive project outline. Additionally, I will define the structure of the test classes and determine the necessary methods, particularly those required in STDLIB. Furthermore, I aim to engage in discussions with mentors to collaborate on the implementation process. Also, I will make a list of all prerequisite packages that can be used while implementing this project runner and if there are any non-implemented prerequisite packages, I intend to discuss it with mentors.
Week 1: During this week I will start with implementing any non-implemented prerequisite package and then implement the test class and its methods like “ok”, “equal”, “throws”, “deepEqual”, “end”, “notEqual” and others.
Expected folder structure for test-class
Here in index.js, I will implement an constructor which will call all other methods like equal ,notEqual ,pass ,fail ,strictlyEqual, and others.
Assert.js will generate an assertion for different methods.
equal.js, notEqual.js, ok.js, deepEqual.js and similar files will contain definitions for respective methods and all these files will internally call assert method to perform the assertion.
Expected folder structure for runner
clear.js -> Removes any pending tests close.js -> Stops the runner and will return a stream containing a summary of the tests
Create_stream.js -> It will create a result stream using a transform stream and will also include some callbacks to be called upon events like run, and push.
exit.js -> It will forcefully stop the runner push.js -> It will add a new test to the test array run.js -> It will run the first test from the array encode_result.js -> Generates a result that can be shown on the terminal, it will be followed by a summary of results from close.js
Week 4: During this week I will start working on pretests, validations, iterations, and related files which will help me to start the process. I will work on the following files : init.js -> Performs initialization tasks pretest.js -> Runs pretests to check all the requirements validate.js -> validates the function options index.js -> Entry Point for the code, it will call the runner and test class and then return a results stream with the help of a logger .
Week 5: During this week I will start my work on the logger and address any backlogs or bugs that may have accumulated from previous weeks.
To create the logger, I will create a transform stream that will process all the incoming data, accumulate it, and output each line to the console as soon as a newline character is encountered.
Week 6: (midterm) Till this week my aim is to have a functional test runner in place and work on any bugs or backlogs if present.
Week 7 and Week 8: During this week I will work on suggestions provided during the midsem review and will work on writing benchmarks, tests, and examples for our test runner.
Week 9 and Week 10: During these weeks I will work on making docs for this test runner and will work on any suggestions from mentors or if any bugs are introduced. Also, I will work on any remaining tasks if left from previous weeks. Also, I am planning to do extensive testing of our test runner and handle errors if any.
Week 11 and Week 12: During this week I will work on migrating packages from tape to our newly built test runner.
I intend to automate the refactoring process by employing Python scripts and leveraging the stream editor (Sed) alongside regular expressions. SED command in UNIX stands for stream editor and it can perform lots of functions on files like searching, finding and replacing, and insertion. Through this approach, I will manipulate files, apply regex patterns to locate and substitute text, and efficiently refactor code by targeting specific keywords or patterns for modification. This strategy offers a systematic way to automate refactoring tasks effectively.
Related issues
No response
Checklist
[RFC]:and succinctly describes your proposal.