Development
Summary
Generate the .txt file in the PR along with the XML File
To implement this feature, we would need to make changes to the current codebase of the SPDX online tool.
When a user submits a new license request through the tool, the tool generates an XML file and submits a PR
to the SPDX License List GitHub repository. To generate a .txt test file in addition to the XML file, we
would need to modify the existing code to extract the necessary information from the user's input and create
a text file with the required details.
To achieve this, we would need to modify the following files:
- `views.py`:
This file is responsible for handling the submission of new license requests through the tool. We
would need to modify this file to
- `generateXml.py`:
This file is responsible for generating the XML file for each license request. We would need to
modify this file to extract the necessary information from the user's input and use it to generate
the .txt test file.
Differentiate Exceptions from License Submission
To implement this feature, we will need to add a checkbox in the submission form to indicate whether the
submission is for a license or an exception. This will allow the tool to differentiate between a license and
an exception and use the appropriate tag when creating the XML file and the pull request.
To achieve this, we will first modify the submission form to include the checkbox, which will then be
included in the POST request sent to the server. We will then modify the server code to process the checkbox
and use the appropriate tag when creating the XML file.
Add or fix unit tests & Improve error handling
-
Write GitHub tests with mocks:
To write tests for GitHub API interaction with mock, we will be using the `requests-mock` package.
This package allows us to mock requests to any external APIs, including GitHub APIs.
To start, we will create a new Python file named `test_github.py` in the tests directory. In this
file, we will import the necessary modules and create a test class for the GitHub API tests. We will
then create methods for each test case that we want to run.
-
Separate tests in multiple files:
To separate the current tests for different features, we can create separate files for each feature.
For example, we can create a file named `test_license.py` for license related tests and another file
named `test_ui.py` for UI tests. Another example would be if there are tests for the XML creator
feature, those tests should be in a file named `test_xml_creator.py`.
We can then run all the tests using a test runner like` pytest` by specifying the directory where
the test files are located. Here is an example command to run all the tests in the tests directory.
This makes it easier to manage the tests.
-
Adding tests for edge cases:
To add tests for edge cases, we need to identify the possible scenarios that may cause issues in our
application. For example, we can add tests for license submissions with invalid data, or for
exceptions that do not follow the SPDX format.
-
Tests for UI on browser e.g.: Chrome:
To add UI tests, we can use a testing framework like `Selenium`. Selenium allows us to automate
browser interactions and test the functionality of our web application.
For testing the UI on a browser like Chrome, we can make use of an automated testing framework like
Selenium. Selenium allows us to automate the testing of web applications by simulating user
interactions with the web page. We can write tests in Python using the `Selenium WebDriver API`.
To implement this feature, we need to install Selenium and the ChromeDriver executable. ChromeDriver
is a separate executable that WebDriver uses to control Chrome. Once installed, we can write a
Python test script that uses the Selenium WebDriver API to interact with the web application.
Add linters to the project
Linters are tools that help identify and report errors in code, helping to ensure that the codebase is
of a high quality and follows best practices. The SPDX Online Tools project could benefit from the
addition of linters for Python, JavaScript, HTML, and CSS, which would help to identify and fix issues
in the codebase.
Python linters such as Pylint, Flake8, and Pyflakes can help to identify errors, potential bugs, and
code smells in Python code. JavaScript linters like ESLint can detect issues such as unused variables,
missing semicolons, and incorrect variable scoping. HTML linters like HTMLHint can check for issues such
as invalid markup and accessibility errors. Finally, CSS linters like Stylelint can help identify errors
such as invalid selectors, unused styles, and syntax errors.
The linters could be integrated into the development process, either through the use of pre-commit hooks
or as part of a continuous integration (CI) pipeline. When a developer commits code, the linters would
run and report any issues. This would help to catch errors early in the development process, before they
become larger problems.
The use of linters can also help to improve the readability and maintainability of the codebase. By
enforcing consistent coding styles and conventions, the codebase becomes easier to read and understand,
and easier to maintain over time.
Overall, the addition of linters to the SPDX Online Tools project would help to ensure that the codebase
is of a high quality and follows best practices, while also improving the readability and
maintainability of the codebase.
