Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
李少辉-开发者
gitlab-foss
提交
760d611b
G
gitlab-foss
项目概览
李少辉-开发者
/
gitlab-foss
通知
15
Star
0
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
G
gitlab-foss
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
760d611b
编写于
1月 11, 2018
作者:
G
Grzegorz Bizon
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Copy-edit docs about GitLab QA page objects
上级
02500992
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
13 addition
and
13 deletion
+13
-13
qa/qa/page/README.md
qa/qa/page/README.md
+13
-13
未找到文件。
qa/qa/page/README.md
浏览文件 @
760d611b
...
...
@@ -19,18 +19,18 @@ We need page objects, because we need to reduce duplication and avoid problems
whenever someone changes some selectors in GitLab's source code.
Imagine that we have a hundred specs in GitLab QA, and we need to sign into
GitLab each time, before we make assertions. Without
page object one would nee
d
to rely on volatile helpers or invoke Capybara methods directly. Imagine
GitLab each time, before we make assertions. Without
a page object one woul
d
need
to rely on volatile helpers or invoke Capybara methods directly. Imagine
invoking
`fill_in :user_login`
in every
`*_spec.rb`
file / test example.
When someone later changes
`t.text_field :login`
in the view associated with
this page to
`t.text_field :username`
it will generate
different field ID,
what would effectively break all 100
tests.
this page to
`t.text_field :username`
it will generate
a different field
identifier, what would effectively break all
tests.
Because we are
now
using
`Page::Main::Login.act { sign_in_using_credentials }`
everywhere, whe
re we want to sign into GitLab, page object is the single sourc
e
of truth, and we will need to update
`fill_in :user_login`
to
`fill_in :user_username`
only in a one place
as well
.
Because we are using
`Page::Main::Login.act { sign_in_using_credentials }`
everywhere, whe
n we want to sign into GitLab, the page object is the singl
e
source
of truth, and we will need to update
`fill_in :user_login`
to
`fill_in :user_username`
only in a one place.
## What problems did we have in the past?
...
...
@@ -38,9 +38,9 @@ We do not run QA tests for every commit, because of performance reasons, and
the time it would take to build packages and test everything.
That is why when someone changes
`t.text_field :login`
to
`t.text_field :username`
in
new session view we won't know about this change
until our GitLab QA nightly pipeline runs, or someone triggers
`package-qa`
action in their merge request.
`t.text_field :username`
in
the _new session_ view we won't know about this
change until our GitLab QA nightly pipeline fails, or until someone triggers
`package-qa`
action in their merge request.
Obviously such a change would break all tests. We call this problem a _fragile
tests problem_.
...
...
@@ -53,11 +53,11 @@ problem by introducing coupling between GitLab CE / EE views and GitLab QA.
Currently, when you add a new
`Page::Base`
derived class, you will also need to
define all selectors that your page objects depends on.
Whenever you
r
push your code to CE / EE repository,
`qa:selectors`
sanity test
Whenever you push your code to CE / EE repository,
`qa:selectors`
sanity test
job is going to be run as a part of a CI pipeline.
This test is going to validate all page objects that we have implemented in
`qa/page`
directory. When i
f
fails, you will be notified about missing
`qa/page`
directory. When i
t
fails, you will be notified about missing
or invalid views / selectors definition.
## How to properly implement a page object?
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录