В настоящий момент занимаюсь реализацией взаимодействия с поставщиком KYC услуг. Как обычно ничего космического. Нужно просто выбрать из своей базы данных некий достаточно объемный комплект экземпляров различных записей, выгрузить их поставщику услуг и попросить поставщика записи эти проверить.

Начальная стадия обработки содержит десяток идентичных операций с отправкой запросов на извлечение данных некоего конкретного пользователя из различных таблиц базы. Есть предположение что при этом достаточно большую часть кода можно будет использовать повторно в виде абстракции Request. Попробую предположить как этим можно было бы пользоваться. Напишу первый тест:

describe('Request', () => {

    const Request = require('./Request');

    it('execute should return promise', () => {

        const request = new Request();

        request.execute().then((result) => {

            expect(result).toBeNull();
        });
    });
});

Выглядит вроде неплохо? Возможно неидеально, но на первый взгляд похоже что Request это по сути команда, которая возвращает Promise с результатом? С этого вполне можно начать. Набросаю код, чтобы тест можно было запустить.

class Request {

    constructor(){}

    execute(){
        return new Promise((resolve, reject) => {
            resolve(null);
        });
    }
}
module.exports = Request;

Выполняю npm test и наблюдаю в консоли зеленую точку выполнившегося теста.

Итак. У меня есть запрос, и он умеет выполнятся. В реальности однако, мне надо будет каким-то образом информировать мой запрос о том, в какой таблице ему следует искать нужные данные и каким критериям эти данные должны соответствовать. Попробую написать новый тест:

it('should configure request', () => {

    const options = {
        tableName: 'users',
        query: {  id: 1 }
    };
    request.configure(options);

    expect(request.options).toEqual(options);
});

Нормально? На мой взгляд вполне. Поскольку у меня есть теперь уже два теста, в которых используется экземпляр переменной request, то инициализацию этой переменной я вынесу в специальный метод, выполняющийся перед запуском каждого теста. Таким образом в каждом тесте у меня будет свежий экземпляр объекта запроса:

let request = null;

beforeEach(() => {
    request = new Request();
});

Реализую этот функционал в классе запроса, добавлю в него метод, который сохраняет настройки в переменной экземпляра класса, как это и демонстрирует тест.

configure(options){
    this.options = options;
}

Запускаю выполнение тестов и вижу теперь уже две зеленых точки. Два моих теста успешно выполнились. Однако. Предполагается однако что запросы мои будут адресоваться базе данных. Сейчас уже пожалуй стоит попробовать посмотреть с какой стороны запрос будет получать информацию о базе данных. Вернусь к тестам и напишу какой-нибудь код:

const DbMock = require('./DbMock');
let db = null;

beforeEach(() => {
    db = new DbMock();
    request = new Request(db);
});

Мне кажется такой вот классический вариант инициализации через конструктор вполне удовлетворяет моим текущим требованиям.

Естественно я не собираюсь в модульных тестах использовать интерфейс к реальной базе данных MySQL, с которой работает наш проект. Почему? Потому что:

Если вместо меня, кому то из моих коллег потребуется поработать над этой частью проекта, и выполнить модульные тесты то прежде, чем они смогут хоть что-нибудь сделать, им придется потратить силы и время на установку, и настройку собственного экземпляра сервера MySQL.
Успешность выполнения модульных тестов, будет зависеть от правильности предварительного заполнения данными, используемой базы сервера MySQL.
Время запуска тестов с использованием базы данных MySQL будет значительно более длительным.

Ладно. А почему бы к примеру не задействовать в модульных тестах какую-нибудь базу данных в памяти? Работать она будет быстро, а процесс ее настройки и инициализации можно автоматизировать. Все так, но в настоящий момент я не вижу никаких преимуществ от использования этого дополнительного инструмента. Мне кажется что мои текущие потребности быстрее и дешевле (не нужно тратить время на изучение) можно удовлетворить с помощью классов и методов заглушек и псевдообъектов, которые будут лишь имитировать поведение интерфесов, которые предполагается использовать в боевых условиях.

Кстати. В боевых условиях я предполагаю использовать bookshelf в связке с knex. Почему? Потому что следуя документации по установке, настройке и использованию этих двух инструментов, мне удалось за несколько минут создать и выполнить запрос к базе данных.

Что из этого следует? Из этого следует что я должен доработать код класса Request так, чтобы выполнение запроса соответствовало интерфейсам, экспортируемым моим боевым инструментам. А значит теперь код должен выглядеть вот так:

class Request {

    constructor(db){
        this.db = db;
    }

    configure(options){
        this.options = options;
    }

    execute(){
        const table =
            this.db.Model.extend({
                tableName: this.options.tableName
            });

        return table.where(this.options.query).fetch();
    }
}
module.exports = Request;

Запущу тесты и посмотрю что происходит. Ага. У меня конечно же отсутствует модуль DbMock, так что первым делом реализую для него заглушку:

class DbMock {
    constructor(){}
}

module.exports = DbMock;

Запущу тесты еще раз. Что теперь? Теперь принцесса Jasmine сообщает мне что мой DbMock не реализует свойство Model. Попробую придумать что-нибудь:

class DbMock {

    constructor(){
        this.Model = {
            extend: () => {}
        };
    }
}

module.exports = DbMock;

Снова запускаю тесты. Теперь ошибка в том, что в моем модульном тесте, я запускаю выполнение запроса, не выполнив предварительно настройку его параметров с помощью метода configure. Исправляю это:

const options = {
    tableName: 'users',
    query: { id: 1 }
};

it('execute should return promise', () => {

    request.configure(options);

    request.execute().then((result) => {

        expect(result).toBeNull();
    });
});

Поскольку экземпляр переменной options у меня используется уже в двух тестах, то я выношу его в код инициализации всего тестового набора и снова запускаю выполнение тестов.

Как и предполагалось, метод extend, свойства Model, класса DbMock вернул нам undefined, в связи с этим естественно у нашего запроса нет никакой возможности вызвать метод where.

Я уже сейчас понимаю что свойство Model, класса DbMock — следует реализовать за пределами собственно класса DbMock. В первую очередь из-за того, что реализация заглушек необходимых чтобы имеющиеся тесты выполнились, потребует слишком большого количества вложенных областей видимости при инициализации свойства Model прямо в классе DbMock. Это будет совершенно невозможно читать и понимать… И это однако не остановит меня от такой попытки, потому что я хочу убедиться что у меня по-прежнему есть возможность написать всего несколько строчек кода и заставить тесты выполниться успешно.

Итак. Вдох, выдох, слабонервным покинуть помещение. Дополняю реализацию конструктора DbMock. Та-даааамммм....

class DbMock {

    constructor(){
        this.Model = {
            extend: () => {
                return {
                    where: () => {
                        return {
                            fetch: () => {
                                return new Promise((resolve, reject) => {
                                    resolve(null);
                                });
                            }
                        };
                    }
                };
            }
        };
    }
}

module.exports = DbMock;

Жесть! Однако твердой рукой запускаем тесты и убеждаемся что Jasmine снова показывает нам зеленые точки. А это значит мы все еще на правильном пути, хотя кое-что у нас непозволительно опухло.

Что дальше? Невооруженным глазом видно что свойство Model псевдо-базы данных должно быть реализовано как нечто совершенно отдельное. Хотя навскидку и не понятно как оно должно быть реализовано.

Зато я совершенно точно знаю что записи в этой псевдо-базе прямо сейчас я буду хранить в самых обыкновенных массивах. И поскольку для имеющихся тестов мне нужна только имитация таблицы users, то для начала я реализую массив пользователей, с одной записью. Но для начала, напишу тест:

describe('Users', () => {

    const users = require('./Users');

    it('should contain one user', () => {

        expect(Array.isArray(users)).toBeTruthy();
        expect(users.length).toEqual(1);

        const user = users[0];

        expect(user.Id).toEqual(1);
        expect(user.Name).toEqual('Jack');
    });
});

Запускаю тесты. Убеждаюсь что они не проходят, и реализую свой нехитрый контейнер с пользователем:

const Users = [
    { Id: 1, Name: 'Jack' }
];

module.exports = Users;

Теперь тесты выполняются, а мне приходит в голову что семантически Model, в пакете bookshell это поставщик интерфейса доступа к содержимому таблицы в базе. Не зря же мы в метод extend передаем объект с именем таблицы. Почему он называется extend, а не к примеру get, я не знаю. Возможно это просто недостаток знаний об API bookshell.

Ну да бог с ним, ибо теперь у меня в голове есть идея на тему следующего теста:

describe('TableMock', () => {

    const container = require('./Users');
    const Table = require('./TableMock');
    const users = new Table(container);

    it('should return first item', () => {

        users.fetch({ Id: 1 }).then((item) => {

        expect(item.Id).toEqual(1);
        expect(item.Name).toEqual('Jack');
        });
    });
});

Поскольку в моменте мне нужна реализация, лишь имитирующая функциональность реального драйвера хранилища, то я классы я именую соответствующим образом, добавляя суффикс Mock:

class TableMock {

    constructor(container){
        this.container = container;
    }

    fetch() {
        return new Promise((resolve, reject) => {
            resolve(this.container[0]);
        });
    }
}

module.exports = TableMock;

Но fetch не единственный метод, который я предполагаю использовать в боевой версии, так что добавляю еще один тест:

it('where-fetch chain should return first item', () => {

    users.where({ Id: 1 }).fetch().then((item)=> {

        expect(item.Id).toEqual(1);
        expect(item.Name).toEqual('Jack');
    });
});

Запуск которого, как и положено отображает мне сообщение об ошибке. Так что дополняю реализацию TableMock, методом where:

where(){
return this;
}

Теперь тесты выполняются и можно переходить к размышлениям на тему реализации свойства Model в классе DbMock. Как я уже предполагал, это будет некий поставщик экземпляров объектов типа TableMock:

describe('TableMockMap', () => {

    const TableMock = require('./TableMock');
    const TableMockMap = require('./TableMockMap');
    const map = new TableMockMap();

    it('extend should return existent TableMock', () => {

        const users = map.extend({tableName: 'users'});

        expect(users instanceof TableMock).toBeTruthy();
    });
});

Почему TableMockMap, потому что семантически это оно и есть. Просто вместо имени метода get, используется имя метода extend.

Поскольку тест падает, делаем реализацию:

const Users = require('./Users');
const TableMock = require('./TableMock');

class TableMockMap extends Map{

    constructor(){
        super();
        this.set('users', Users);
    }

    extend(options){

        const container = this.get(options.tableName);

        return new TableMock(container);
    }
}

module.exports = TableMockMap;

Запускаем тесты и видим шесть зеленых точек в консоли. Жизнь прекрасна.

Как мне кажется прямо сейчас уже можно избавиться от страшной пирамиды инициализации в конструкторе класса DbMock, воспользовавшись замечательным TableMockMap. Не будем откладывать это, тем более что неплохо бы уже было бы выпить чаю. Новая реализация восхитительно изящна:

const TableMockMap = require('./TableMockMap');

class DbMock {

    constructor(){
        this.Model = new TableMockMap();
    }
}

module.exports = DbMock;

Запускаем тесты… и упс! Наш самый главный тест падает. Но это даже и хорошо, потому что это был тест-заглушка и теперь мы просто обязаны его исправить:

it('execute should return promise', () => {

    request.configure(options);

    request.execute().then((result) => {

        expect(result.Id).toEqual(1);
        expect(result.Name).toEqual('Jack');
    });
});

Тесты выполнились успешно. И теперь можно сделать перерыв, а затем вернуться к доработке получившегося кода запроса, потому что он еще весьма и весьма далек не то что от совершенства, но даже и от просто удобного в использовании интерфейса, не смотря на то, что данные с его помощью из базы уже можно получать.

Разработка команды запроса данных из базы