Поблочное тестирование в веб-приложениях то использование базы данных
При нажатии кнопки «Удалить» вызовите эту функцию:
onDeleteClick() {
this.dialog.close({action: 1, data: this.data});
}
Здесь action и 1 - произвольные значения, могут быть любыми.
Теперь, в компоненте, из которого вы открыли диалог, используйте эту функцию:
import { Component, OnInit,Input } from '@angular/core';
import { Service } from '../service';
import { map } from 'rxjs/operators';
import { IContact } from '../models';
import {MAT_DIALOG_DATA, MatDialog, MatDialogRef, MatListOption} from '@angular/material';
import { DeleteComponent } from '../delete/delete.component';
@Component({
selector: 'app-customer',
templateUrl: './customer.component.html',
styleUrls: ['./customer.component.css']
})
export class CustomerComponent implements OnInit {
@Input()
data;
contacts:IContact[];
someContact:IContact[];
constructor(public dialog: MatDialog,
public customersServiceList: Service) {}
public async ngOnInit(): Promise<void> {
this.contacts = await this.customersServiceList.getContactList();
}
public openDialogDelete($event: any): void {
this.dialog.open(DeleteComponent, {
width: '350px',data:$event,
}).afterClosed().subscribe(data => {
if(data && data.action === 1) {
this.onDelete(data.data);
}
});
}
public onDelete(data: any) {
console.log('called');
this.someContact = data;
console.log(this.someContact);
}
}
8 ответов
Это не модульный тест при тестировании больше чем одной единицы.
Обычно у Вас будет один компонент (Ваша страница или бизнес-слой) говорящий с расположенным на слое объектом данных, который ответственен за то, что на самом деле соединил и запросил базу данных. Моя рекомендация состоит в том, чтобы разработать модульный тест на первый компонент, с помощью внедрения зависимости для передачи в ложной версии DataLayer (который действует на hardcoded данные или Список, который Вы передаете в, и т.д.). Таким образом, Вы тестируете свой высокоуровневый код в изоляции от других компонентов.
Затем Вы свободны разработать другие модульные тесты (и интеграционные тесты), чтобы слой данных гарантировал, что обрабатывает, это - задание (пишущий в базу данных) правильно.
Мы используем базу данных в оперативной памяти (hsqldb) для наших модульных тестов. В установке мы заполняем его с данными тестирования и затем перед каждым тестовым сценарием, мы запускаем транзакцию и после каждого тестового сценария, мы прокручиваем его транзакция назад. Это означает, что каждый тестовый сценарий имеет чистый запуск дб.
Michael Feathers утверждает, что тестирует, которые общаются с базами данных, не модульные тесты по определению. Главной причиной для этого является точка, которую Вы поднимаете: модульные тесты должны быть простыми и легкими для выполнения.
Это не должно говорить, что Вы не должны тестировать код базы данных. Но Вы не хотите считать их модульными тестами. Таким образом, если Вы делаете какое-либо тестирование базы данных, Вы хотите разделить тесты от остальной части Ваших модульных тестов.
Стоимость поблочного тестирования / TDD - то, что необходимо изменить дизайн так, чтобы у Вас было чистое разделение между базой данных и доменным слоем, так, чтобы можно было создать фальшивку, которая позволит Вам создавать тесты, которые не поражают базу данных.
Но тот более чистый дизайн является только началом стоимости. После этого необходимо создать тесты, которые и помогают Вам заставить код работать правильно в первый раз и предупредить Вас, когда любой повреждает что-то, что это раньше работало.
И после того, как у Вас есть хороший фундаментальный дизайн с тестами, которые защищают Вашу существующую функциональность, Вы очистите код помогать работать с с уверенностью, Вы не повреждаете вещи по пути.
И так далее и так далее... Затраты на поблочное тестирование / TDD просто продолжают укладку со временем.
Решение Дразнит. Насмешки "заменяют" соединение. Единица под тестом "соединится" с Насмешкой и выполняет свой оператор. Насмешка возвращает нормальные наборы результатов o.s.e.
После теста насмешка может дать Вам список всех методов, которые назвала единица под тестом. Easymock.org
Как другой сказанный: соединение с БД не является модульным тестом. Так отбросьте его и сделайте это локальный с Насмешкой объектов
Так как я использовал Доктрину для своей работы базы данных PHP, и так как Доктрина имеет уровень абстракции запроса (названный DQL), я могу выгрузить бэкэнды, не имея необходимость волноваться слишком много о проблемах совместимости. Так в этом случае для моих модульных тестов я был бы только в начале моих тестов загружать схему и приспособления в дб SQLlite, тестировать мои модели и отбрасывать дб SQLlite в конце тестирования.
Таким образом, я протестировал свои модели и доступ к данным, чтобы удостовериться, что их запросы формируются правильно.
Теперь тестируя определенный экземпляр базы данных для проверки текущая схема корректна, другая история и по моему скромному мнению вероятно, не принадлежит Модульных тестов, так поскольку это принадлежит списка задач развертывания.
Это кажется на фактическое желание функционального / интеграционного тестирования. Для веб-приложений я рекомендую изучить Селен или Canoo WebTest.
Они являются также большими для автоматизации задач, которые Вы делаете в сети. У меня есть комплект установки и комплект разрушения, которые создают предприятия и пользователей тестирования через администраторский интерфейс, а также тесты для стоящего с клиентом сайта.
Для Java можно также хотеть изучить dbunit. http://www.dbunit.org/