Add Best Practices to Kaspresso Wiki #162
Conversation
| └── java | ||
| └── com | ||
| ├── actions | ||
| ├── app_providers |
There was a problem hiding this comment.
Использование нижних подчеркиваний в названиях пакетов противоречит
https://developer.android.com/kotlin/style-guide#package_names
| ``` | ||
|
|
||
| 1. **App_providers** | ||
| Put here all helper classes wich contains some business logic of main application. For example, if you need to use some Dagger component and check state of your interactor. **Don't use this interactors directly,** put accessing to interactors into method-wrappers witch returns some primitive or void for some simple actions and then call this methods in your test cases. |
There was a problem hiding this comment.
state of your interactor
О каком состоянии интерактора речь? Интерактор - это функция, состояние хранится в репозитории.
**Don't use this interactors directly
Не понял, что подразумевается по "прямым" и не "прямым" использованием. Давай добавим примеры.
**Don't use this interactors directly
Почему? К каким последствиям это может привести?
There was a problem hiding this comment.
Да, стоит чуть подраскрыть. Человеку, который не в контексте, будет тяжело понять, что к чему.
| ├── screens | ||
| ├── screenshot_tests | ||
| ├── tests | ||
| └── views |
There was a problem hiding this comment.
Нет описания, что это за пакет и какие там views хранятся
| ``` | ||
|
|
||
| 3. **Functional** | ||
| This package needed for converting end-to-end tests into functional, for example it's may be working with DI, stub's and Advice. (Here is more about [Advice](#Advices)) |
There was a problem hiding this comment.
Такие тесты обычно называют интеграционными. Почему functional?
There was a problem hiding this comment.
Я согласен, что нужно переименовать, ибо функциональные тесты сами по себе немного про другое
@RuslanMingaliev как назовем?
There was a problem hiding this comment.
Надо пообщаться с нашим QA, чтобы не было недопониманий
| 3. **Functional** | ||
| This package needed for converting end-to-end tests into functional, for example it's may be working with DI, stub's and Advice. (Here is more about [Advice](#Advices)) | ||
| 4. **Scenarios** | ||
| There you can hold your mostly repeated steps wrapped into scenarios. In common it created with kotlin stateless objects. But you can hold some parameters for some logic and in this case create classic class with constructor parameters. We highly recommend to separate scenarios if it contains so many steps and logic. (Here is some more about [`scenario`](https://github.com/KasperskyLab/Kaspresso/blob/master/wiki/04_How_to_write_autotests.md#test-structure-1)) |
There was a problem hiding this comment.
if it contains so many steps and logic
лучше давать количественную характеристику, а не качественную. Не понятно, 100 шагов норм или уже нет
|
|
||
| 1. First rule of writing best test cases: inheritors of `TestCase` class must be exactly test cases or class wich overrides **must be applied to all test cases**. If you create multiple parent classes you may get pain with modifying and ordering classes or your new cases may do some work wich them must not to do. | ||
|
|
||
| But if you still needed to add some actions to group of cases you can create lamda-function with `Kaspresso.Builder` (here is more about [`Kaspresso.Bulder`](https://github.com/KasperskyLab/Kaspresso/blob/master/wiki/03_Kaspresso_configurator.md)) receiver and pass it as class parameter. You still can use `before` and `after` sections in test case but also you will have `beforeEachTest` and `afterEachTest`. Example: |
There was a problem hiding this comment.
add some actions to group of cases
Если речь только про beforeEachTest и afterEachTest, то это не some actions, а конкретные actions. Нельзя добавить шаги куда-то в середину. Кажется, мы тут вводим в заблуждение.
| ## Other advices | ||
|
|
||
| 1. Don't be afraid to read source code of called methods. For example you can discover that method `androidx.test.uiautomator.UiDevice.pressBack()` calling `waitForIdle()` before perfoming click. This waiting by default keep 10 seconds timeout and may not execute if screen still drawing some changes. | ||
| And if you go deeper in code researching you can find configurator of uiAutomator and change default timeout of `waitForIdle()`. |
There was a problem hiding this comment.
Технология называется UI Automator
|
|
||
| ```kotlin | ||
| /** | ||
| * More efficient simple waiting then Thread.sleep |
There was a problem hiding this comment.
More efficient
Стоит указать, чем эффективнее
| } | ||
| ``` | ||
|
|
||
| 3. There is difference of `device.targetContext` and `device.context`. First one used if you need context of **application witch will be tested** (host application) and second one if you need context of **application wich testing your main application** (slave application). |
There was a problem hiding this comment.
Откуда терминология host application и slave application?
| } | ||
| ``` | ||
|
|
||
| 5. Use `assertSafely` constructions. From naming you can realise that it's [`flakySafely`](https://github.com/KasperskyLab/Kaspresso/blob/master/wiki/04_How_to_write_autotests.md#flakysafely), for assertions and used when your assert may be appear with some delay. Also you can set custom message of error. |
There was a problem hiding this comment.
Что за конструкция assertSafely? Неплохо было бы увидеть пример. Из описания не понятно, что это и чем отличается от flakySafely
|
Английский нужно вычитывать. Нашел много грамматических, пунктуационных и синтаксических ошибок. |
| ... | ||
| step("some step") { | ||
| MainScreen { | ||
| Accessibility.run { enable() } // without invoke override |
|
|
||
| ## File structure | ||
|
|
||
| Here is shown an example structure of packages. It's not strong rule but we higly recommend to organize your files. |
There was a problem hiding this comment.
An example of the package structure is shown here. It's not a very strict rule but we strongly recommend organizing your files in such an order.
| └── java | ||
| └── com | ||
| ├── actions | ||
| ├── app_providers |
| ├── screens | ||
| ├── screenshot_tests | ||
| ├── tests | ||
| └── views |
| ``` | ||
|
|
||
| 1. **App_providers** | ||
| Put here all helper classes wich contains some business logic of main application. For example, if you need to use some Dagger component and check state of your interactor. **Don't use this interactors directly,** put accessing to interactors into method-wrappers witch returns some primitive or void for some simple actions and then call this methods in your test cases. |
| ``` | ||
|
|
||
| 1. **App_providers** | ||
| Put here all helper classes wich contains some business logic of main application. For example, if you need to use some Dagger component and check state of your interactor. **Don't use this interactors directly,** put accessing to interactors into method-wrappers witch returns some primitive or void for some simple actions and then call this methods in your test cases. |
|
|
||
| For describing views use childs of KView (kakao views). | ||
|
|
||
| ### KExternalScreen |
There was a problem hiding this comment.
ну мы же специально разделяли UiScreen и немного проапгреденный KExternalScreen
|
|
||
| ### KExternalScreen | ||
|
|
||
| If you want write autotests with external screens (when your app use another app, like Chrome or Gmail) you can create class for external screens, for example |
There was a problem hiding this comment.
If you want write autotests with external screens (when your app use another app, like Chrome or Gmail) you can create class for external screens, for example
Нужно написать, что бывают случаи, когда из тестов мы юзаем другие приложения, но и в этих случаях лучше придерживать паттерна PO и описывать каждый экран. Для описания экранов внешних приложений можно использовать KExternalScreen, который по своей сути очень походит на KScreen.
И вот в таком духе описывай.
| } | ||
| ``` | ||
|
|
||
| Or if you don't want to override `invoke` you may not use generics. |
|
|
||
| ## Advices | ||
|
|
||
| If you want to separate end-to-end and functional test cases in single code of test we recommend to use interfaces and we named it `Advice` (but you can name it as you want). For example we want to pass registration on web-portal in our application. In e2e we must perform real registration but on functional we can stub it. So let's write some code: |
There was a problem hiding this comment.
Нужно вообще начинать с проблемы.
Прям бери с нашего с Мовчаном выступления.
There was a problem hiding this comment.
Почему "advice"?)))
| ## Advices | ||
|
|
||
| If you want to separate end-to-end and functional test cases in single code of test we recommend to use interfaces and we named it `Advice` (but you can name it as you want). For example we want to pass registration on web-portal in our application. In e2e we must perform real registration but on functional we can stub it. So let's write some code: | ||
|
|
There was a problem hiding this comment.
Ниже не стал проходиться сильно, так как основные моменты описаны уже выше.
Каждый пункт нужно начинать с истории, проблемы, продолжать примерами и четким разъяснением.
PR нужно еще серьезно дорабатывать, но начало положено.
close #131