-
Notifications
You must be signed in to change notification settings - Fork 36
Automatic Testing
Unit tests are automated assessments specifically created to validate the functionality of individual elements within our application. These tests serve to ensure that our code components, such as functions and modules, perform correctly in isolation. By identifying and rectifying issues at this granular level, we enhance the overall reliability and maintainability of our application.
Key Characteristics of our Unit Tests:
- Focus on isolated code units.
- Swift and efficient.
- Detect logic and functional errors early in development.
- Data integrity is ensured among all components of the software.
https://github.com/specify/specify7/tree/production/specifyweb/frontend/js_src/lib#tests
Tests can be run with npm run test
while in the /specifyweb/frontend/js_src/
directory.
The frontend tests utilize the Jest Testing Framework. For additional information, view their documentation.
Examples:
- Fetch Pick List Items Unit Tests:
This set of unit tests focuses on the fetchPickListItems function, which retrieves items from a pick list. The tests verify that it can correctly retrieve items from different types of pick lists, such as pick lists generated from items, pick lists sourced from entire database tables, and pick lists derived from entire columns within a table.
- Field Format Unit Tests:
These unit tests are designed to evaluate the fieldFormat function, which handles formatting values for a specific field in our application. The tests ensure that it handles various scenarios correctly. For example, the test named "handles pick list in parser" checks if the function can correctly format a value when a pick list is involved, and the test "handles pick list assigned to a field" verifies the formatting when a pick list is directly assigned to a field.
Snapshots:
Snapshot tests are designed to evaluate the visual aspects of our user interface (UI). They capture the current UI output of specific components or screens and store these as reference images. During testing, snapshots compare the present UI output to the stored references, highlighting any unintended changes in appearance.
Key Characteristics of our Snapshot Tests:
- Detect unexpected UI alterations.
- Primarily assess UI appearance, not functionality.
- Valuable for maintaining a consistent UI design.
To sum up, our front-end testing process comprises two main types of tests: unit tests and snapshots. Unit tests focus on the correctness of our front-end code, assessing individual functions and components. Meanwhile, snapshot tests concentrate on the visual integrity of our UI, ensuring its consistency. Our backend unit tests in Django creates mock test data in order to test the functionality of our code.
Tests can be run by executing the manage.py
using python with the test
argument in the backend container.
This can be accomplished using the following command which can be run from the terminal (specify7-specify7-1
is the name of the backend container in this case):
docker exec -it specify7-specify7-1 bash -c "ve/bin/python3 manage.py test"
The backend tests utilize the testing framework within the Django library. If additional information is needed, view their documentation.
Examples:
- MultipleAgentsException is being properly raised
This unit test ensures that the MultipleAgentsException
error is raised by the backend when a Client attempts to assign more than one Agent per Division to a Specifyuser when calling the set_user_agents endpoint
It's important to understand that our testing procedures are designed to be completely separate from the database used in our application. Our tests primarily focus on the front-end components and functionality, as mentioned.
The separation of database testing is essential for a couple of reasons: Isolation of Testing: Our unit tests and snapshots are primarily concerned with front-end functionality, user interface, and code components. We deliberately isolate these tests from the database to ensure that any issues related to the database or its data do not interfere with our front-end testing. Data Independence: By keeping the database separate from our tests, we avoid unintentional alterations to the data. This allows us to run tests without affecting the integrity of the actual database, ensuring that our tests do not inadvertently modify or interfere with real data.
In summary, our testing procedures are designed to be database-agnostic. They primarily focus on the front-end aspects of our application, ensuring that the user interface and functionality work as expected.