Saleor Commerce Testing
![Saleor Commerce Testing](https://testrigor.flowxllc.com/wp-content/uploads/2024/01/Saleor-Commerce-Logo.png)
Saleor is a widely used open-sourced e-commerce platform. It offers a high-performance, customizable framework for building online stores and e-commerce platforms. It gives greater flexibility in designing the user interface. Saleor includes GrapgQL, a flexible data query language, and a headless architecture separating the back and front end.
It is created in Python with the Django web framework. In addition, as discussed earlier, Saleor uses GraphQL for its API. GraphQL is more efficient, robust, and flexible than traditional REST API. The front end is developed using JavaScript frameworks like React.
When it comes to testing the Saleor application, we can follow through the Testing Pyramid.
Unit Testing
The preliminary level of testing done in an application is unit testing. Here, we test the application in the early development stages to capture the bugs at very early stages. We isolate and test the individual units of the code, helping us test the exact functionality. The individual unit can be a function, class, or method.
We can use two tools to perform unit testing for Saleor applications.
- Django’s Built-in Test Framework
- Pytest
Let’s go through each one by one.
Django’s Built-in Test Framework
Django has the built-in testing framework that extends Python’s standard unittest library. This test framework is designed to test models, forms, and templates. Suppose any database update is involved in the application code that needs to be unit tested; creating a temporary database is better. This ensures the production or development database won’t be affected.
Once we install all the dependencies, we can start writing test scripts. The test files are kept in a separate tests directory, or we can also create a separate tests.py for every application file. It’s always recommended to extend django.test.TestCase, as this class provides many helper methods and classes for testing purposes. Once the scripts are created, we can execute them using the manage.py command.
from django.test import TestCase from .models import Product class ProductTestCase(TestCase): def setUp(self): Product.objects.create(name="Test Product 1", price=50, description="A simple product") Product.objects.create(name="Test Product 2", price=200, description="An expensive product") def test_product_creation(self): """Test the product creation.""" product1 = Product.objects.get(name="Test Product 1") product2 = Product.objects.get(name="Test Product 2") self.assertEqual(product1.description, "A simple product") self.assertEqual(product2.price, 200) def test_product_string_representation(self): """Test the string representation of the product.""" product = Product.objects.get(name="Test Product 1") self.assertEqual(str(product), "Test Product 1") def test_is_expensive(self): """Test the is_expensive method of the product.""" cheap_product = Product.objects.get(name="Test Product 1") expensive_product = Product.objects.get(name="Test Product 2") self.assertFalse(cheap_product.is_expensive()) self.assertTrue(expensive_product.is_expensive())
pytest
pytest is a standard Python testing framework. pytest is famous for its simplicity, flexibility, and powerful features. To test Saleor applications, we first need to install pytest and its Django integration package. Once that is complete, we must create pytest.ini for the tool configuration. Once we have done with the setup, we can start creating unit tests.
Here, the tests are saved in the tests folder, and all the test files will start with the name “test_”.
import pytest from products.models import Product @pytest.fixture def product(db): return Product.objects.create(name="Test Product", price=100, available=True) def test_product_creation(product): assert product.name == "Test Product" assert product.price == 100 def test_product_availability(product): assert product.is_available() is True # Change availability and test again product.available = False assert product.is_available() is False
Integration testing
The next level of testing is integration testing. Here, we combine the units to check how they perform when integrated. So here, more than the individual component functionality, we are testing the functionality when the system gets integrated; if the system can work flawlessly when integrated, that’s tested.
We can use the below-mentioned tools for performing integration testing:
- Django Test Client
- pytest-django
- Postman
Let’s go through each of the tools.
Django Test Client
from django.test import TestCase from django.urls import reverse from .models import Product class ProductListViewTest(TestCase): @classmethod def setUpTestData(cls): # Set up data for the whole TestCase Product.objects.create(name="Test Product 1", price=100) def test_view_url_exists_at_desired_location(self): response = self.client.get('/products/') self.assertEqual(response.status_code, 200) def test_view_url_accessible_by_name(self): response = self.client.get(reverse('products:list')) self.assertEqual(response.status_code, 200) def test_view_uses_correct_template(self): response = self.client.get(reverse('products:list')) self.assertEqual(response.status_code, 200) self.assertTemplateUsed(response, 'products/product_list.html') def test_pagination_is_ten(self): response = self.client.get(reverse('products:list')) self.assertTrue('is_paginated' in response.context) self.assertTrue(response.context['is_paginated'] == True) self.assertTrue(len(response.context['product_list']) == 10)
pytest-django
First, we need to install pytest-django. Once installed, we must configure it by creating a configuration file, pytest.ini. pytest-django has a dependency on pytest, so in our script, we need to extend pytest so that the fixtures, markers, and assertions can be used. The setting and configuration of pytest-django are similar to that of pytest.
Postman
Using Postman, we can test the API integration between different layers. Since Saleor uses GraphQL, we can use Postman to conduct API integration tests. Postman is a popular tool used for API testing. Using it, we can create a collection of API requests that mocks the production or development usage of the application. We can test not only the responses but also the structure, data integrity, and performance.
End-to-end testing
E2E testing is performed when the application is fully developed and ready to test the use cases. So, more than testing the functionality, E2E testing focuses on testing from an end-user perspective. It ensures the application use case conditions meet the requirements. Since Saleor is into e-commerce platforms, E2E testing is critical to satisfy customers’ expectations. So, let’s see which tools we can use for E2E testing.
Selenium
As we all know, end-to-end testing won’t be complete without mentioning the Selenium tool. Selenium is the legacy tool in web automation testing, which supports most programming languages. It has significantly fewer integrations as an open source, but we can integrate many different applications and reports.
But as the market got more aggressive, software development moved to Agile and Extreme Programming, where automation needs to be on par with development. This was not possible for Selenium to achieve. The major drawback was the code complexity. As the code repository gets bigger and the test case increases, the code debugging and maintenance become a nightmare.
Also, the dependency on flaky element locators lost the trust of execution results as there were many false positive bugs. There were many limitations to using Selenium, paving the way for companies to make Selenium not a preferred E2E tool.
Anyway, there are a lot of tutorials for Selenium available on the internet. Here is one posted in our blogs: Selenium Test Example.
testRigor
testRigor can be defined as a generative AI-driven, intelligent, and codeless automation tool that allows you to write test cases in plain English. Let’s just go through a few capabilities of testRigor:
- Generative AI: testRigor can generate test cases or test data based on the test description we provide. It makes the testers’ lives extremely easy by saving a lot of time and effort for them.
- Free from programming languages: Yes, that’s correct. Using testRigor, we can create or edit the test scripts in parsed plain English, eliminating the dependency on programming languages. This feature supports both QA and anyone from the development, management, BA, marketing, or any other stakeholder to create, edit, or execute test scripts.
- Say goodbye to Flaky XPaths: testRigor doesn’t rely on flaky XPaths; it has its way of defining the elements called testRigor locators. Just mention the text as you see on the screen to identify the element; AI takes care of the rest.
We can mention these as AI features, but tetsRigor features continue further. testRigor can be cited as the test powerhouse, as it supports different types of tests like:
- Web and mobile browser testing
- Mobile App Testing
- Desktop App Testing
- API Testing
- Visual Testing
- Accessibility Testing
- Load Testing
Also, testRigor supports inbuilt integration with different tools.
open url "https://yoursaleorcommercesite.com" enter stored value "UserName" into "User Name" enter stored value "password" into "Password" click "Sign in" click “Purchase Orders” click “Create New Purchase Order” enter "John" into "Vendor Name" enter "Vending Machine" into "Items to be Ordered" enter "5" into "Items to be Ordered" click "Submit"
Reviewing the above script, we can easily understand how simple and easily readable it is from others. That’s the advantage that testRigor puts forth. Have a look at the powerful features of testRigor.
EndNotes
E-commerce sites are mostly exposed to a massive spectrum of people, so the scenarios or use cases that need to be tested are countless. It is not just the use cases; the functionalities must also be robust, making every testing phase very critical.
Here, we have analyzed a few tools commonly used for each testing phase. Understanding your requirements and selecting the most suitable tool that saves overall testing time, effort, and cost will always be better.