There are a few cases where code contains human readable messages. Examples are log entries and exception messages. These kinds of messages typically are sentences like “there was a problem communicating with the server, please try again later.” It is usually important to check that log messages are written and exceptions are raised in tests. One of the approaches for these tests is to check that the exact message was written or raised. These kind of messages are subject to change to make them clearer to users which makes tests that check for the exact content of the messages prone to fail whenever the wording is adjusted. In this post we will explore some alternative approaches to writing these kind of tests that are less prone to false failures.
Continue reading “Checking for specific messages in tests”Tag: test
Should this code be in the test or a fixture?
There is some overlap between what could go into the setup phase of a test or into a fixture. There are a few reason why certain pieces of setup code are better suited to a fixture and also why other code might be better off in the test itself. This post explores a few examples to help illustrate how you can decide where to put the setup code to minimise the maintenance cost and maximise the value of the test suit.
Continue reading “Should this code be in the test or a fixture?”Is This Code Worth Testing?
Many of us face this question on a daily basis. In many cases, the answer is yes. In certain cases, the answer is no or somewhere in between. It is important to weigh the benefits against the cost, and consider the extent to which code should be tested. A code coverage tool may report a line of code as covered, but that does not guarantee it has been thoroughly tested. Another consideration is the kinds of tests we write to begin with. For example, should a private function have tests? Or should it be covered by the tests of a public function that makes use of it? Should a function be covered by integration tests or end to end tests? We will explore these questions by examining several examples of code and determine whether and which types of tests are worth writing.
Continue reading “Is This Code Worth Testing?”Navigating Mocks in Python: Strategies for Safe and Efficient Mock Usage
Do you spend a lot of time on maintaining your mocks? Has your test suite passed and your code failed to run in production? This could be a result of using mocks too aggressively or not utilising safety features provided by Python’s mock library. In this post, we will explore the benefits and potential risks of using mocks, discuss strategies for designing high-level interfaces that are safe to mock, and examine a linter tool that ensures safe mock usage. Let’s begin by examining the potential risks associated with using mocks.
Continue reading “Navigating Mocks in Python: Strategies for Safe and Efficient Mock Usage”Writing Great Test Documentation
Have you ever needed to understand a new project and started reading the tests only to find that you have no idea what the tests are doing? Writing great test documentation as you are writing tests will improve your tests and help you and others reading the tests later. We will first look at why test documentation is important both when writing tests and for future readers and then look at a framework that helps give some structure to your test documentation. Next, we will look at a showcase of the flake8-test-docs tool that automates test documentation checks to ensure your documentation is great! Finally, we briefly discuss how this framework would apply in more advanced cases, such as when you are using fixtures or parametrising tests.
Reduce Duplication in Pytest Parametrised Tests using the Walrus Operator
Do you find yourself having to repeat literal values (like strings and integers) in parametrised tests? I often find myself in this situation and have been looking for ways of reducing this duplication. To show an example, consider this trivial function:
def get_second_word(text: str) -> str | None:
"""Get the second word from text."""
words = text.split()
return words[1] if len(words) >= 2 else None
Testing Python Connexion Optional Query Parameter Names
connexion is a great tool for building APIs in Python. It allows you to make the openAPI specification define input validation that is automatically enforced, maps API endpoints to a named function and handles JSON serialising and de-serialising for you.
One of the things to keep in mind when using connexion is that, if you have defined query parameters, only the query parameters that you have define can every get passed to the functions handling the endpoint. For example, consider the following API specification for retrieving employees from a database:
specification.yml
# specification.yml
openapi: "3.0.0"
info:
title: Sample API
description: API demonstrating how to check for optional parameters.
version: "0.1"
paths:
/employee:
get:
summary: Gets Employees that match query parameters.
operationId: library.employee.search
parameters:
- in: query
name: join_date
schema:
type: string
format: date
required: false
description: Filters employees for a particular date that they joined the company.
- in: query
name: business_unit
schema:
type: string
required: false
description: Filters employees for a particular business unit.
- in: query
name: city
schema:
type: string
required: false
description: Filters employees for which city they are working in.
responses:
200:
description: Returns all the Employees in the database that match the query parameters.
content:
application/json:
schema:
type: object
properties:
first_name:
description: The first name of the Employee.
type: string
last_name:
description: The last name of the Employee.
type: string
If you call /employee with some_parameter, you don’t receive an error because connexion will not call your function withsome_parameter as it is not defined as a query parameter in the specification and hence gets ignored. To help prove that, consider the following project setup.
Project Setup
The above specification.yml is included in the root directory. The library folder is also in the root directory. Inside the library folder is the following __init__.py file:
library/__init__.py
# library.__init__.py
from . import employee
The library folder contains the employee folder which has the following __init__.py and controller.py files:
library/employee/__init__.py
library/employee/controller.py
# library.employee.__init__.py
from .controller import search
# library.data.employee.controller.py
def search(join_date = None, business_unit = None, city = None):
return [{'first_name': 'David', 'last_name': 'Andersson'}]
Test Setup
pytest is used to test the API. To help with the API tests, pytest-flask is used. To show that calling the /employee endpoint with parameters that aren’t in the specification does not result in an error, the following test configuration is placed in the root directory:
conftest.py
# conftest.py
from unittest import mock
import pytest
import connexion
import library
@pytest.fixture(scope='session')
def setup_mocked_search():
"""Sets up spy fr search function."""
with mock.patch.object(library.employee, 'search', wraps=library.employee.search) as mock_search:
yield mock_search
@pytest.fixture(scope='function')
def mocked_search(setup_mocked_search):
"""Resets search spy."""
setup_mocked_search.reset_mock()
return setup_mocked_search
@pytest.fixture(scope='session')
def app(setup_mocked_search):
"""Flask app for testing."""
# Adding swagger file
test_app = connexion.FlaskApp(__name__, specification_dir='.')
test_app.add_api('specification.yml')
return test_app.app
For now, focus on the app fixture which uses the standard connexion API setup and then yields the flask application. Through the magic of purest-flask, we can then define the following test to demonstrate that the API can be called with parameters not named in the openAPI specification:
def test_some_parameter(client):
"""
GIVEN a value for some parameter
WHEN GET /employee is called with the some_parameter set to the some parameter value
THEN no exception is raised.
"""
client.get('/employee?some_parameter=value 1')
Verifying Endpoint Parameter Names
This means that making a mistake with the query parameter names in the openAPI specification and the arguments for the function that handles the endpoint can go undetected. To check this is not the case, you could come up with a number of tests that only pass if the query parameter was correctly passed to the search function. This can be tedious without mocking the search function as you would have to create tests with just the right setup so that the effect of a particular query parameter is noticed.
There is an easier way with mocks. Unfortunately, it is not as easy as monkey patching the search function in the body of a test function. The problem is that, after the app fixture has been called, the reference to the search function has been hard coded into the flask application and will not get affected by mocking the search function. It is possible to retrieve the reference to the search function in the flask application instance, but you will have to dig fairly deep and may have to use some private member variables, which is not advisable.
Instead, let’s take another look at the contest.py file above. The trick is to apply a spy to the search function before the app fixture is invoked. The reason a spy rather than a mock is used is because the spy will be in p0lace for all tests and we may want to write a test where the real search function is called! With a spy the underlying function still gets called, which it does not if a mock is used instead of the search function. The fixture on lines 8-12 adds a spy to the search function. To ensure that it gets called before the app fixture, the app fixture takes it as an argument, although it doesn’t make use of the fixture. Because the app fixture is a session level fixture, we also want the fixture that sets up the spy to be a session level fixture, otherwise all the tests will be slowed down. However, this means that the spy state will leak into other tests. This can be solved with a fixture similar to the fixture on lines 15-19 which resets the spy state before each test.
Now we can use the test client to define tests that check that each of the query parameters is passed to the search function. The tests that perform these checks may look like the following:
test.py
# test.py
"""Endpoint tests for /employee"""
def test_some_parameter(client, mocked_search):
"""
GIVEN library.data.employee.search has a spy and a value for some parameter
WHEN GET /employee is called with the some_parameter set to the some parameter value
THEN library.data.employee.search is called with no parameters.
"""
client.get('/employee?some_parameter=value 1')
# Checking search call
mocked_search.assert_called_once_with()
def test_join_date(client, mocked_search):
"""
GIVEN library.data.employee.search has a spy and a date
WHEN GET /employee is called with the join_date set to the date
THEN library.data.employee.search is called with the join date.
"""
client.get('/employee?join_date=2000-01-01')
# Checking search call
mocked_search.assert_called_once_with(join_date='2000-01-01')
def test_business_unit(client, mocked_search):
"""
GIVEN library.data.employee.search has a spy and a business unit
WHEN GET /employee is called with the business_unit set to the business unit
THEN library.data.employee.search is called with the business unit.
"""
client.get('/employee?business_unit=business unit 1')
# Checking search call
mocked_search.assert_called_once_with(business_unit='business unit 1')
def test_city(client, mocked_search):
"""
GIVEN library.data.employee.search has a spy and a city
WHEN GET /employee is called with the city set to the city
THEN library.data.employee.search is called with the city.
"""
client.get('/employee?city=city 1')
# Checking search call
mocked_search.assert_called_once_with(city='city 1')
You now have a starting point for how to test that the function arguments and query parameter names in the specification match. You may not want to create these tests for each query parameter for every endpoint, especially if a query parameter is required, as an exception will be raised because the underlying function will be called with a query parameter which is not listed in the function signature.
Parametrize Angular Jasmine Tests
Functions that map a value from one form to another are useful since you can separate the mapping logic from things like services and components which are best kept as simple as possible. This allows for easy tests where you can check a range of conditions which might take a lot more boilerplate code if the logic was embedded in a component or service. It also allows you to re-use the mapping.
This does lead to simpler test cases, but because they are so simple the test boilerplate can become repetitive and overwhelm what is actually being tested. In practice, these types of tests are often copied and pasted which can lead to more maintenance overhead or outdated commentary around tests. To illustrate, consider the following mapping function.
Transformating Function
The following function takes in a number and returns numbers based on a series of conditional checks.
transform.ts
// transform.ts
export function transform(value: number): number {
if (value === undefined) {
return 0;
}
if (value === null) {
return 0;
}
if (value < 0) {
return -1;
}
if (value === 0) {
return 0;
}
return 1;
}
Traditional Tests
To test the function you might come up with cases where the input is undefined, null, -10, -1, 0, 1 and 10. Those seem reasonable given the checks and boundaries in the tests. This would result in something like the following test file.
transform.spec.ts
// transform.spec.ts
import { transform } from './transform';
describe('transform', () => {
describe('input value is undefined', () => {
it('should return 0', () => {
expect(transform(undefined)).toEqual(0);
});
});
describe('input value is null', () => {
it('should return 0', () => {
expect(transform(null)).toEqual(0);
});
});
describe('input value is -10', () => {
it('should return -1', () => {
expect(transform(-10)).toEqual(-1);
});
});
describe('input value is -1', () => {
it('should return -1', () => {
expect(transform(-1)).toEqual(-1);
});
});
describe('input value is 0', () => {
it('should return 0', () => {
expect(transform(0)).toEqual(0);
});
});
describe('input value is 10', () => {
it('should return 1', () => {
expect(transform(10)).toEqual(1);
});
});
describe('input value is 1', () => {
it('should return 1', () => {
expect(transform(1)).toEqual(1);
});
});
});
The key pieces of information in the tests is that undefined and null map to 0, negative numbers map to -1, 0 maps to 0 and positive numbers map to 1. Compare that simple sentence to 43 lines of code required to implement the tests.
Parametrized Tests
The following shows how the 43 lines of test code can be reduced to 18.
transform.parametrized.spec.ts
// transform.parametrized.spec.ts
import { transform } from './transform';
describe('transform parametrized tests', () => {
// Defining input value and expected transformation
[
{ inputValue: undefined, expectedValue: 0 },
{ inputValue: null, expectedValue: 0 },
{ inputValue: -10, expectedValue: -1 },
{ inputValue: -1, expectedValue: -1 },
{ inputValue: 0, expectedValue: 0 },
{ inputValue: 1, expectedValue: 1 },
{ inputValue: 10, expectedValue: 1 }
].forEach(({inputValue, expectedValue}) => {
describe(`input is ${inputValue}`, () => {
it(`should return ${expectedValue}`, () => {
expect(transform(inputValue)).toEqual(expectedValue);
});
});
});
});
Lines 7 to 13 clearly demonstrate the expected input to output mapping. Lines 15-19 demonstrate how the mapping is achieved. The forEach loop takes advantage of object destructing to assign an object from the array to parameters of the testing function on line 14. The describe and it functions are passed arguments that include the input and expected value, which makes reading and understanding the output of failed tests easier, on lines 15 and 16, respectively.
There are drawbacks to parametrizing tests and, in a lot of cases, can make tests confusing. In this case, the parameters and code to execute the test fit on the same page in a code editor, which makes it easy to understand. There are also few input parameters and the test logic is simple.
When the number of input parameters gets large, it makes the test harder to read because you have to jump back and forth between the parameter definition and the test code. If the test code is longer and complex, introducing parameters increases the complexity of the test even further. If parametrizing the test means you have to significantly increase the logic of the test, it means the test is hard to understand when you come back to it a few months down the track.
However, with few input parameters and a function for which little test logic is required, using parametrised tests reduces boilerplate code and makes the tests easier to understand. TypeScript also helps as it will infer the types of the input and expected parameters for you.
Testing the Testing Guard Decorator in Python
Testing functions in Python that have a decorator applied to them is not ideal as the tests have to be written to take into account the decorator. The testing guard decorator can help remove the problem by selectively running the function with or without the decorator by detecting the environment in which it is run. When you make the decorator a part of your project you might like to write tests for the testing guard decorator itself.
Testing Guard Decorator
As a reminder, the following is the decorator code for the testing guard.
# testing_guard.py
"""Demonstrates a guard decorator."""
import os
def testing_guard(decorator_func):
"""
Decorator that only applies another decorator if the appropriate
environment variable is not set.
Args:
decorator_func: The function that applies the decorator.
Returns:
Function that dynamically decides whether to apply the decorator based
on the environment.
"""
def replacement(original_func):
"""
Function that is used as the decorator function instead of the
decorator function.
Args:
original_func: The function being decorated.
Returns:
Function that dynamically picks between the original and
decorated function depending on the environment.
"""
# Creating decorated function
decorated_func = decorator_func(original_func)
def apply_guard(*args, **kwargs):
"""
Dynamically picks between decorated and original function based on
environment.
"""
if os.getenv('TESTING') is not None:
# Use original function
return original_func(*args, **kwargs)
# Use decorated function
return decorated_func(*args, **kwargs)
return apply_guard
return replacement
The key pieces of functionality are on lines 39-43. Line 39 is the check for whether the function is being executed in the testing environment. If it is, the original function is called without the decorator on line 41. If it isn’t, then the decorated function is called on line 43. The key reason that the decorator works is that it gets access to both the decorator and original function and that it gets to run code every time the decorated function is run.
Testing the Testing Guard Decorator
There are 2 scenarios to test. The first is that the decorator is executed in the test environment, and the second is when it is executed in the non-test environment. In both cases we care about both that the correct function is called with the correct arguments (and that the other function is not called) and that the return value from the correct function is returned.
Let’s first define 2 fixtures that will help during testing. We will repeatedly need some generic *args and **kwargs and the particular value we choose for either doesn’t add anything to help understand the tests themselves so it is better to hide that detail in a fixture.
@pytest.fixture(scope='session')
def args():
"""Generates function *args"""
return ('arg1', 'arg2')
@pytest.fixture(scope='session')
def kwargs():
"""Generates function **kwargs"""
return {'kwargs1': 'kwarg1', 'kwarg2': 'kwarg2'}
Test Environment
When the decorator is executed in the test environment, it should call the original function and return the return value of the original function. It should not call the decorator return value. To focus the tests, let’s split those into three separate tests.
The first test just checks that the decorator return value is not called:
def test_testing_guard_set_decorated_call(monkeypatch):
"""
GIVEN TESTING environment variable is set and mock decorator
WHEN decorator is applied to a function after decorating it with the
testing guard and calling the decorated function
THEN decorator return value is not called.
"""
# Setting TESTING environment variable
monkeypatch.setenv('TESTING', '')
# Defining mock decorator
mock_decorator = mock.MagicMock()
# Decorating with testing guard and calling
guarded_mock_decorator = testing_guard(mock_decorator)
# Applying decorator
mock_decorated_func = guarded_mock_decorator(mock.MagicMock())
# Calling function
mock_decorated_func()
# Checking decorator call
mock_decorator.return_value.assert_not_called()
To understand the test, some understanding of Python decorators is required. A decorator is another function whose return value replaces the function it is decorating. A decorator could, for example, return the print function and then the function being decorator would never be called. In most cases, however, the function being decorator is called in the body of the function the decorator returns.
On line 9 of the test the testing environment is setup. On line 11 a mock function that will serve as the decorator to which the testing guard is applied is defined. On line 14 the testing guard is applied to the mock decorator. Then a mock function is decorated with guarded mock decorator on line 16 and the decorated function is called on line 18. On line 21 it is checked that the return value of the decorator, which would usually be called instead of the original function, is not called since, in the testing environment, the original function should always be called.
The next test checks that the original function is called with the correct arguments. For this we will ned the args and kwargs fixtures.
def test_testing_guard_set_func_call(monkeypatch, args, kwargs):
"""
GIVEN TESTING environment variable is set, mock function and args and
kwargs
WHEN a decorator is applied to the function after decorating it with the
testing guard and calling the decorated function with args and kwargs
THEN function is called with args and kwargs.
"""
# Setting TESTING environment variable
monkeypatch.setenv('TESTING', '')
# Defining mock decorator
mock_func = mock.MagicMock()
# Decorating with testing guard and calling
mock_decorator = mock.MagicMock()
guarded_mock_decorator = testing_guard(mock_decorator)
# Applying decorator
mock_decorated_func = guarded_mock_decorator(mock_func)
# Calling function
mock_decorated_func(*args, **kwargs)
# Checking decorator call
mock_func.assert_called_once_with(*args, **kwargs)
This tests is very similar to the first test but, instead of keeping track of the decorator, the original function is defined on line 12. The procedure on lines 14-20 is very similar to the first test with the only difference being that the mock decorated function is called with the args and kwargs fixtures. On line 23 the original function call is checked.
The final test checks the return value of the mock decorated function call. It is much like the previous test, except that it doesn’t pass in any args nor kwargs.
def test_testing_guard_set_return(monkeypatch):
"""
GIVEN TESTING environment variable is set and mock function
WHEN a decorator is applied to the function after decorating it with the
testing guard and calling the decorated function
THEN the return value is the function return value.
"""
# Setting TESTING environment variable
monkeypatch.setenv('TESTING', '')
# Defining mock function
mock_func = mock.MagicMock()
# Decorating with testing guard and calling
mock_decorator = mock.MagicMock()
guarded_mock_decorator = testing_guard(mock_decorator)
# Applying decorator
mock_decorated_func = guarded_mock_decorator(mock_func)
# Calling function
return_value = mock_decorated_func()
# Checking decorator call
assert return_value == mock_func.return_value
Non-Test Environment
The second series of tests are outside the test environment. Since the tests for the testing guard are likely running inside the test environment, it is usually best to deactivate the testing environment as a part of the test as you may want to have the testing environment active by default during your tests.
The tests are very similar to the tests in the test environment. The difference is that now the decorator return value should be called, the original function should not be called and the return value of the decorator return value should be returned. The tests are shown below.
def test_testing_guard_not_set_decorated_call(monkeypatch, args, kwargs):
"""
GIVEN TESTING environment variable is not set, mock decorator and args and
kwargs
WHEN decorator is applied to a function after decorating it with the
testing guard and calling the decorated function with args and kwargs
THEN decorator return value is called with args and kwargs.
"""
# Removing TESTING environment variable
monkeypatch.delenv('TESTING', raising=False)
# Defining mock decorator
mock_decorator = mock.MagicMock()
# Decorating with testing guard and calling
guarded_mock_decorator = testing_guard(mock_decorator)
# Applying decorator
mock_decorated_func = guarded_mock_decorator(mock.MagicMock())
# Calling function
mock_decorated_func(*args, **kwargs)
# Checking decorator call
mock_decorator.return_value.assert_called_once_with(*args, **kwargs)
def test_testing_guard_not_set_return(monkeypatch):
"""
GIVEN TESTING environment variable is not set and mock decorator
WHEN decorator is applied to a function after decorating it with the
testing guard and calling the decorated function
THEN the return value is the decorator's return value return value.
"""
# Removing TESTING environment variable
monkeypatch.delenv('TESTING', raising=False)
# Defining mock decorator
mock_decorator = mock.MagicMock()
# Decorating with testing guard and calling
guarded_mock_decorator = testing_guard(mock_decorator)
# Applying decorator
mock_decorated_func = guarded_mock_decorator(mock.MagicMock())
# Calling function
return_value = mock_decorated_func()
# Checking decorator call
assert return_value == mock_decorator.return_value.return_value
def test_testing_guard_not_set_func_call(monkeypatch):
"""
GIVEN TESTING environment variable is not set and mock function
WHEN a decorator is applied to the function after decorating it with the
testing guard and calling the decorated function
THEN function is not called.
"""
# Removing TESTING environment variable
monkeypatch.delenv('TESTING', raising=False)
# Defining mock decorator
mock_func = mock.MagicMock()
# Decorating with testing guard and calling
mock_decorator = mock.MagicMock()
guarded_mock_decorator = testing_guard(mock_decorator)
# Applying decorator
mock_decorated_func = guarded_mock_decorator(mock_func)
# Calling function
mock_decorated_func()
# Checking decorator call
mock_func.assert_not_called()
This demonstrates how to test the testing guard. The setup and teardown of your test environment might be more complicated in which case your tests would have to reflect that.
Testing Angular Material Basic Spreadsheet
Previously, you had an idea to move a spreadsheet from an email trail onto a website. To achieve that, you used an Angular Material Basic Spreadsheet. You showed it to your manager and he thought it had potential if you add a few more features. Before going ahead with that, you realise that, to achieve complexity scale, you will have to start writing some tests.
As a reminder, the key elements of the Angular Material Basic Spreadsheet are the component that displays individual orders. This component is used by an Angular Material table based table component that maps a number of orders onto the screen similar to a spreadsheet based on the date and product of the order, as shown below.
Testing Individual Order Component
The following is the code and template behind the individual order component.
order.component.ts
order.component.html
// order.component.ts
import { Component, OnInit, Input } from '@angular/core';
import { Order } from './order.model';
@Component({
selector: 'app-order',
templateUrl: './order.component.html',
styleUrls: ['./order.component.css']
})
export class OrderComponent implements OnInit {
@Input() order: Order;
constructor() { }
ngOnInit() {
}
}
<!-- order.component.html -->
<ng-container *ngIf="order">{{ order.value | number }}</ng-container>
To figure out the tests that need to be written, let’s think about what could go wrong. Firstly, we could have forgotten to import something or setup something incorrectly. Next, we could have assumed that anyone that uses the component will always pass in an order. Thirdly, when an order is passed in, we could have forgotten to use the number pipe to display the value. The following specification tests for those three cases.
order.component.spec.ts
// order.component.spec.ts
import { TestBed, ComponentFixture } from '@angular/core/testing';
import { OrderComponent } from './order.component';
import { DebugElement } from '@angular/core';
describe('OrderComponent', () => {
let fixture: ComponentFixture<OrderComponent>;
let component: OrderComponent;
let debugElement: DebugElement;
beforeEach(() => {
TestBed.configureTestingModule({
declarations: [OrderComponent]
});
fixture = TestBed.createComponent(OrderComponent);
component = fixture.componentInstance;
debugElement = fixture.debugElement;
});
it('should create', () => {
fixture.detectChanges();
expect(component).toBeTruthy();
});
describe('order null', () => {
it('should display empty template.', () => {
// Setting order to null
component.order = null;
// Triggering change detection
fixture.detectChanges();
// Checking template
expect(debugElement.nativeElement.textContent).toEqual('');
});
});
describe('order not null', () => {
it('should display order value formatted as number.', () => {
// Setting order to null
component.order = {date: '2000-01-01', product: 'product 1', value: 1000};
// Triggering change detection
fixture.detectChanges();
// Checking template
expect(debugElement.nativeElement.textContent).toEqual('1,000');
});
});
});
On lines 8-20 the standard setup for component tests is defined. The test on lines 22-25 checks that the component is created. The test on lines 27-38 checks what happens if the input Order is null. Finally, the test on lines 40-51 checks that the Order value is displayed using the number pipe.
Here the DebugElement is used to inspect the template. Since the template is relatively simple, we only ever check the text content of the whole template under the different test cases.
Testing Table Component
The following is the code and template for the order table component.
order-table.component.ts
order-table.component.html
// order-table.component.ts
import { Component, OnInit } from '@angular/core';
import { OrderTable } from './order-table.model';
import { OrderService } from './order.service';
@Component({
selector: 'app-order-table',
templateUrl: './order-table.component.html',
styleUrls: ['./order-table.component.css']
})
export class OrderTableComponent implements OnInit {
orderTable: OrderTable;
productHeader = 'Product';
headers: string[];
constructor(private orderService: OrderService) { }
ngOnInit() {
this.orderTable = this.orderService.getOrderTable();
this.headers = [this.productHeader].concat(this.orderTable.headers);
}
}
<!-- order-table.component.html -->
<ng-container *ngIf="orderTable.rowLabels.length">
<table mat-table [dataSource]="orderTable.rowLabels" class="mat-elevation-z8">
<ng-container [matColumnDef]="header" *ngFor="let header of headers">
<th mat-header-cell *matHeaderCellDef>
<ng-container *ngIf="header === productHeader">{{ header }}</ng-container>
<ng-container *ngIf="header !== productHeader">{{ header | date }}</ng-container>
</th>
<td mat-cell *matCellDef="let element">
<ng-container *ngIf="header === productHeader">{{ element }}</ng-container>
<ng-container *ngIf="header !== productHeader"><app-order [order]="orderTable.orderMap[header][element]"></app-order></ng-container>
</td>
</ng-container>
<tr mat-header-row *matHeaderRowDef="headers"></tr>
<tr mat-row *matRowDef="let row; columns: headers;"></tr>
</table>
</ng-container>
The table component is more complex and will require more tests. Broadly, there are tests for the component class and for the template. The main test for the component class is that the getOrderTable function is called on initialisation. Ideally, component code is tested without the use of the TestBed as it tends to slow down tests. However, since the component code to be tested is linked to an Angular event (OnInit), in this case it is better to use the TestBed and, therefore, the standard Angular lifecycle functions. The template tests are complex due to the number of ngIf statements and other logic in the template. Additionally, there are some complexities testing Angular Material tables. The following is the test code that checks common cases.
order-table.component.spec.ts
// order-table.component.spec.ts
import { TestBed, ComponentFixture } from '@angular/core/testing';
import { Component, Input } from '@angular/core';
import { MatTableModule } from '@angular/material';
import { OrderTableComponent } from './order-table.component';
import { Order } from './order.model';
import { OrderService } from './order.service';
@Component({
selector: 'app-order',
template: `
{{ order.date }}
{{ order.product }}
{{ order.value }}
`
})
class TestOrderComponent {
@Input() order: Order;
}
describe('OrderTableComponent', () => {
let fixture: ComponentFixture<OrderTableComponent>;
let component: OrderTableComponent;
let nativeElement: HTMLElement;
let orderServiceSpy: jasmine.SpyObj<OrderService>;
beforeEach(() => {
// Creating mock OrderService
orderServiceSpy = jasmine.createSpyObj('OrderService', ['getOrderTable']);
TestBed.configureTestingModule({
declarations: [OrderTableComponent, TestOrderComponent],
providers: [{provide: OrderService, useValue: orderServiceSpy}],
imports: [MatTableModule]
});
fixture = TestBed.createComponent(OrderTableComponent);
component = fixture.componentInstance;
nativeElement = fixture.nativeElement;
});
describe('TestOrderComponent', () => {
it('should create', () => {
// Defining getOrderTable return value
orderServiceSpy.getOrderTable.and.returnValue({
headers: [],
rowLabels: [],
orders: [],
orderMap: {}
});
// Triggering change detection
fixture.detectChanges();
// Checking component create
expect(component).toBeTruthy();
});
describe('construction', () => {
it('should call getOrderTable on OrderService', () => {
// Defining getOrderTable return value
orderServiceSpy.getOrderTable.and.returnValue({
headers: [],
rowLabels: [],
orders: [],
orderMap: {}
});
// Triggering change detection
fixture.detectChanges();
// Checking getOrderTable call
expect(orderServiceSpy.getOrderTable).toHaveBeenCalledWith();
});
});
describe('empty table', () => {
it('should display empty template.', () => {
// Defining getOrderTable return value
orderServiceSpy.getOrderTable.and.returnValue({
headers: [],
rowLabels: [],
orders: [],
orderMap: {}
});
// Triggering change detection
fixture.detectChanges();
// Checking template
expect(nativeElement.textContent).toEqual('');
});
});
describe('single item table', () => {
it('should display Product and date header', () => {
// Defining getOrderTable return value
const order = {
date: '2000-01-01',
product: 'product 1',
value: 1
};
orderServiceSpy.getOrderTable.and.returnValue({
headers: ['2000-01-01'],
rowLabels: ['product 1'],
orders: [order],
orderMap: {'2000-01-01': {'product 1': order}}
});
// Triggering change detection
fixture.detectChanges();
// Checking headers in template
const trs = nativeElement.querySelectorAll('tr');
expect(trs.length).toEqual(2);
const ths = trs.item(0).querySelectorAll('th');
expect(ths.length).toEqual(2);
['Product', 'Jan 1, 2000'].forEach((expectedHeader, idx) => expect(ths.item(idx).innerText).toEqual(expectedHeader));
});
it('should display single row with Order', () => {
// Defining getOrderTable return value
const order = {
date: '2000-01-01',
product: 'product 1',
value: 1
};
orderServiceSpy.getOrderTable.and.returnValue({
headers: ['2000-01-01'],
rowLabels: ['product 1'],
orders: [order],
orderMap: {'2000-01-01': {'product 1': order}}
});
// Triggering change detection
fixture.detectChanges();
// Checking headers in template
const trs = nativeElement.querySelectorAll('tr');
expect(trs.length).toEqual(2);
const tds = trs.item(1).querySelectorAll('td');
expect(tds.length).toEqual(2);
['product 1', '2000-01-01 product 1 1'].forEach((expectedItem, idx) => expect(tds.item(idx).innerText).toEqual(expectedItem));
});
});
describe('multiple item table with single row', () => {
it('should display Product and date headers', () => {
// Defining getOrderTable return value
const orders = [{
date: '2000-01-01',
product: 'product 1',
value: 1
}, {
date: '2000-01-02',
product: 'product 2',
value: 2
}];
orderServiceSpy.getOrderTable.and.returnValue({
headers: ['2000-01-01', '2000-01-02'],
rowLabels: ['product 1'],
orders: orders,
orderMap: {
'2000-01-01': {'product 1': orders[0]},
'2000-01-02': {'product 1': orders[1]}
}
});
// Triggering change detection
fixture.detectChanges();
// Checking headers in template
const trs = nativeElement.querySelectorAll('tr');
expect(trs.length).toEqual(2);
const ths = trs.item(0).querySelectorAll('th');
expect(ths.length).toEqual(3);
[
'Product', 'Jan 1, 2000', 'Jan 2, 2000'
].forEach((expectedHeader, idx) => expect(ths.item(idx).innerText).toEqual(expectedHeader));
});
it('should display single row with Orders', () => {
// Defining getOrderTable return value
const orders = [{
date: '2000-01-01',
product: 'product 1',
value: 1
}, {
date: '2000-01-02',
product: 'product 1',
value: 2
}];
orderServiceSpy.getOrderTable.and.returnValue({
headers: ['2000-01-01', '2000-01-02'],
rowLabels: ['product 1'],
orders: orders,
orderMap: {
'2000-01-01': {'product 1': orders[0]},
'2000-01-02': {'product 1': orders[1]}
}
});
// Triggering change detection
fixture.detectChanges();
// Checking headers in template
const trs = nativeElement.querySelectorAll('tr');
expect(trs.length).toEqual(2);
const ths = trs.item(1).querySelectorAll('td');
expect(ths.length).toEqual(3);
[
'product 1', '2000-01-01 product 1 1', '2000-01-02 product 1 2'
].forEach((expectedItem, idx) => expect(ths.item(idx).innerText).toEqual(expectedItem));
});
});
describe('multiple item table with single column', () => {
it('should display Product and date header', () => {
// Defining getOrderTable return value
const orders = [{
date: '2000-01-01',
product: 'product 1',
value: 1
}, {
date: '2000-01-01',
product: 'product 1',
value: 2
}];
orderServiceSpy.getOrderTable.and.returnValue({
headers: ['2000-01-01'],
rowLabels: ['product 1', 'product 2'],
orders: orders,
orderMap: {'2000-01-01': {
'product 1': orders[0],
'product 2': orders[1]
}}
});
// Triggering change detection
fixture.detectChanges();
// Checking headers in template
const trs = nativeElement.querySelectorAll('tr');
expect(trs.length).toEqual(3);
const ths = trs.item(0).querySelectorAll('th');
expect(ths.length).toEqual(2);
['Product', 'Jan 1, 2000'].forEach((expectedHeader, idx) => expect(ths.item(idx).innerText).toEqual(expectedHeader));
});
it('should display multiple rows with Orders', () => {
// Defining getOrderTable return value
const orders = [{
date: '2000-01-01',
product: 'product 1',
value: 1
}, {
date: '2000-01-01',
product: 'product 2',
value: 2
}];
orderServiceSpy.getOrderTable.and.returnValue({
headers: ['2000-01-01'],
rowLabels: ['product 1', 'product 2'],
orders: orders,
orderMap: {'2000-01-01': {
'product 1': orders[0],
'product 2': orders[1]
}}
});
// Triggering change detection
fixture.detectChanges();
// Checking headers in template
const trs = nativeElement.querySelectorAll('tr');
expect(trs.length).toEqual(3);
let tds = trs.item(1).querySelectorAll('td');
expect(tds.length).toEqual(2);
['product 1', '2000-01-01 product 1 1'].forEach((expectedItem, idx) => expect(tds.item(idx).innerText).toEqual(expectedItem));
tds = trs.item(2).querySelectorAll('td');
expect(tds.length).toEqual(2);
['product 2', '2000-01-01 product 2 2'].forEach((expectedItem, idx) => expect(tds.item(idx).innerText).toEqual(expectedItem));
});
});
});
});
The test setup is done on lines 23-41. The tests on lines 43-76 check the code of the component. The tests on lines 78-286 check the template under a range of scenarios.
Test Setup for Angular Material Table
There are a few interesting pieces to highlight for the tests. As the OrderTemplateComponent has a dependency on the OrderComponent, it needs to be given to the TestBed along with the OrderTableComponent. For testing, it is better to define a mock implementation of the component rather than use the real component, which is done on lines 10-20.
At the time of writing, the DebugElement does not work with the Angular Material table. This means that, to figure out exactly which OrderComponent is displayed in a cell, we need to make use of the template. Each OrderComponent displays an Order. Therefore, it should be enough to display all the member variables of the Order in the template of the mock OrderComponent to know that the correct Order was passed.
Since the template of the OrderTableComponent makes use of the Angular Material table, we need to pass in the MatTableModule to the TestBed.
Component Code Tests
The tests on lines 43-76 check that the component can be constructed and that the getOrderTable function is called on the OrderService during component initialisation. In this case, the component create test is a little more complicated because the OrderService needs to be called during initialisation which means that the getOrderTable function must at least exist. Also, during the initialisation, the headers member variable is used on the returned value of getOrderTable, so we may as well return an empty OrderTable.
Component Template Tests
The main reason for the length of the tests are the definition of the OrderTable to display in each test. There is a trade off between pre-defining or repeatedly defining them in each test. In production code brevity is preferred, so it is often better to define a range of OrderTables and importing them. However, for tests, it is better to have a single test be as much of a complete story as is needed to understand the test. As what is displayed in the template is tightly linked to the OrderTable, there are significant advantages to explicitly stating the OrderTable in each test.
The test scenarios are an empty table, a single item table and tests where either multiple columns or rows are displayed. In each case, the headers and rows are checked.
With these tests you have made an important step towards being able to scale up the complexity of the website. Now it is time to work on additional features! The most important feature request your manager has made is to make the spreadsheet editable so that people can revise the orders that were placed over time.
David Andersson 