Как делают меня тест-драйв разработка GWT?
Одним из решений является использование HTTPS Cloud Function .
Как объясняется в документе, «после развертывания функции HTTPS вы можете вызывать ее через собственный уникальный URL-адрес». URL будет выглядеть следующим образом: https: // us-central1- .cloudfunctions.net / stripeWebhook, и вам просто нужно объявить его в настройках Stripe.
В облачной функции вы сможете получать значения, передаваемые в тело HTTP-запроса, следующим образом:
exports.stripeWebhook = functions.https.onRequest((req, res) => {
const orderId = req.body.data.object.metadata.orderId;
const sourceId = req.body.data.object.id;
const sourceType = req.body.data.object.type;
....
});
, а также записывать в Firestore, чтобы обновить запись в соответствии с paiement. В качестве примера вы можете посмотреть следующее официальное видео: https://www.youtube.com/watch?v=7IkUgCLr5oA&t=1s&list=PLl-K7zZEsYLkPZHe41m4jfAxUi0JjLgSM&index=3 117
2 ответа
Ведущий UI теста проблематичен, потому что Вы часто не знаете то, что Вы хотите на экране, пока Вы не видите его на экране. По этой причине разработка GUI имеет тенденцию быть в широком масштабе повторяющейся и поэтому очень трудной управлять с тестами.
Это не означает, что мы просто отказываемся от TDD для графический интерфейсов пользователя. Скорее мы продвигаем столько кода, сколько мы возможно можем из GUI, оставляя позади только простой код проводного соединения. То проводное соединение позволяет нам вносить в широком масштабе повторяющиеся изменения, в которых мы нуждаемся, не влияя на сущность проблемы.
Эта техника была, вероятно, лучше всего описана Michael Feathers несколько лет назад в статье, наделенной правом "Скромное Диалоговое окно". Это - также фундаментальная идея позади шаблона Образцового Предъявителя Представления, который вызвал такое движение четыре года назад; и был теперь разделен на Пассивные шаблоны Контроллера Представления и Наблюдения. Ссылка на статью в этом вопросе использует в своих интересах эти идеи, но в тесте - после, а не путь, на котором делают пробную поездку.
Идея - к тест-драйву все кроме представления. Действительно, мы не должны даже писать представление в течение хорошего долгого времени. Действительно, Представление так нелепо просто, что ему, вероятно, не нужен никакой вид модульных тестов вообще. Или если это делает, они могут на самом деле быть записаны в последний раз.
К тест-драйву Контроллер Наблюдения Вы просто удостоверяетесь, что понимаете, как данные будут представлены на экране. Вы не должны знать, где данные, или что шрифт, или что окрашивает, это, или любая из других косметических проблем, которые вызывают крупное повторение графический интерфейсов пользователя. Скорее Вы знаете, что один элемент данных будет некоторым текстовым полем. Другой будет меню, все еще другой будет кнопкой или флажком. И затем Вы удостоверяетесь, что Представление может задать все вопросы, оно должно попросить представлять эти объекты правильно.
Например, текстовое поле может иметь значение по умолчанию. Представление должно смочь попросить его. Меню может иметь некоторые объекты greyed. Представление должно смочь запросить эту информацию. Вопросы, которые задает представление, являются всеми о презентации и лишены бизнес-правил.
К тому же представление скажет Контроллер Наблюдения, когда что-либо изменится. Контроллер изменит данные соответственно, включая любой вид проверки и восстановления после ошибки, и затем Представление может спросить, как те данные должны быть представлены.
Все это может быть тестом, управляемым, потому что он все отделяется от визуального представления. Это - все о том, как данными управляют и представляют, а не о том, на что это похоже. Таким образом, это не должно быть в широком масштабе выполнено с помощью итераций.
I've successfully test-driven the development of Swing and GWT applications through the GUI.
Testing "just behind the GUI" ignores the integration between the model code and the GUI components. The application needs to hook up event handlers to display data in the GUI when the model changes and receive input from the GUI and update the model. Testing that all those event handlers have been hooked up correctly is very tedious if done manually.
The big problem to overcome when testing through the GUI is how to cope with changes to the GUI during development.
GWT has hooks to help with this. You need to set debug IDs on the GWT widgets and import the DebugID module into your application. Your tests can then interact with the application by controlling a web browser, finding elements by their id and clicking on them or entering text into them. Web Driver is a very good API for doing this.
That's only the start, however. You also need to decouple your tests from the structure of the GUI: how the user navigates through the UI to get work done. This is the case whether you test through the GUI or behind the GUI against the controller. If you test against the controller, the controller dictates the way that the user navigates through the application's different views, and so your test is coupled to that navigation structure because it is coupled to the controller.
To address this, our tests control the application through a hierarchy of "drivers". The tests interact with drivers that let it perform user-focused activities, such as logging in, entering an order, and making a payment. The driver captures the knowledge of how those tasks are performed by navigating around and entering data into the GUI. It does this by using lower-level drivers that capture how navigation and data entry is performed by "gestures", such as clicking on a button or entering text into an input field. You end up with a hierarchy like:
- User Goals: the tests verify that the user can achieve their goals with the system and demonstrates how those goals are achieved by a sequence of...
- User Activities: things the user does through the GUI, represented as drivers that perform...
- Gestures: low level mouse and keyboard input to control the GUI.
This hierarchy that is often used in the user-centered design literature (although with different terminology).