Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Sign up
Appearance settings

Commit 8c08397

Browse files
Merge pull request goldbergyoni#112 from koooge/tweak/dot
Tweak: dot
2 parents 0afd174 + 9379538 commit 8c08397

File tree

4 files changed

+12
-12
lines changed

4 files changed

+12
-12
lines changed

‎readme-pt-br.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -70,7 +70,7 @@ Diretrizes para CI no mundo JS (9 tópicos)
7070

7171
<br/>
7272

73-
## ⚪️ 0. A Regra de Ouro: Design para testes enxutos
73+
## ⚪️ 0 A Regra de Ouro: Design para testes enxutos
7474

7575
:white_check_mark: **Faça:**
7676
O código de teste não é como o código de produção - projete-o para ser simples, curto, sem abstrações, plano, agradável de se trabalhar, enxuto. Deve-se olhar para um teste e obter a intenção instantaneamente.
@@ -973,7 +973,7 @@ it("When updating site name, get successful confirmation", async () => {
973973

974974
# Seção 3️⃣: Teste de Frontend
975975

976-
## ⚪ ️ 3.1. Separar UI da funcionalidade
976+
## ⚪ ️ 3.1 Separar UI da funcionalidade
977977

978978
:white_check_mark: **Faça:** Ao focar no teste da lógica dos componentes, os detalhes da interface do usuário se tornam um ruído que deve ser extraído, para que seus testes possam se concentrar em dados puros. Na prática, extraia os dados desejados da marcação de uma maneira abstrata que não seja muito acoplada à implementação gráfica, afirme apenas dados puros (vs detalhes gráficos de HTML/CSS) e desative animações que diminuem a velocidade. Você pode cair na tentação de evitar renderizar e testar apenas a parte de trás da interface do usuário (por exemplo, serviços, ações, armazenamento), mas isso resultará em testes fictícios que não se assemelham à realidade e não revelam casos em que os dados corretos nem chegam na interface do usuário
979979

@@ -1259,7 +1259,7 @@ test('movie title appears', async () => {
12591259

12601260
<br/>
12611261

1262-
## ⚪ ️ 3.5. Veja como o conteúdo é servido na rede
1262+
## ⚪ ️ 3.5 Veja como o conteúdo é servido na rede
12631263

12641264
![](https://img.shields.io/badge/🔧%20Exemplo%20usando%20Google%20LightHouse-blue.svg
12651265
"Exemplo com Lighthouse")

‎readme-zh-CN.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -62,7 +62,7 @@ JS 领域的 CI 指南(9 条)
6262

6363
<br/>
6464

65-
## ⚪️ 0. 黄金法则:设计瘦测试
65+
## ⚪️ 0 黄金法则:设计瘦测试
6666

6767
:white_check_mark: **建议:** 测试代码与生产代码不同,要使它变得极其简单、短小、没有抽象、扁平化、使人愉悦、瘦。一段测试代码需要做到让人一眼就能看出其目的。
6868

@@ -970,7 +970,7 @@ it("When updating site name, get successful confirmation", async () => {
970970

971971
# 第三章: 前端测试
972972

973-
## ⚪ ️ 3.1. 将 UI 与功能分离
973+
## ⚪ ️ 3.1 将 UI 与功能分离
974974

975975
:white_check_mark: **建议:** 当专注于测试组件逻辑时,UI 细节就变成了应该剔除的噪音,这样您的测试就可以集中在纯数据上。实际上,通过抽象从代码中提取所需的数据将降低与图形实现的耦合,仅对纯数据 (vs HTML/CSS 图形细节) 断言,并禁用会拖慢速度的动画。您可能会试图避免渲染,仅测试 UI 后面的部分(例如,服务、操作、存储),但这将导致测试与实际情况不太相符,「正确的数据根本无法到达 UI」这种问题就无法发现。
976976

@@ -1255,7 +1255,7 @@ test('movie title appears', async () => {
12551255

12561256
<br/>
12571257

1258-
## ⚪ ️ 3.5. 观察内容是如何通过网络提供的
1258+
## ⚪ ️ 3.5 观察内容是如何通过网络提供的
12591259

12601260
![](https://img.shields.io/badge/🔧%20Example%20using%20Google%20LightHouse-blue.svg
12611261
"Examples with Lighthouse")

‎readme.kr.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -61,7 +61,7 @@ JavaScript 및 Node.js에 대한 A부터 Z까지의 믿음직한 가이드입니
6161

6262
<br/>
6363

64-
## ⚪ ️ 0. 황금률: 린 테스트를 위한 설계
64+
## ⚪ ️ 0 황금률: 린 테스트를 위한 설계
6565

6666
:white_check_mark: **이렇게 해라:** 테스트 코드는 제품 코드와 다릅니다. 단순하고, 짧고, 추상화가 없고, 무난하고, 작업하기에 편리하고, 린하게 디자인 하십시오. 테스트를 보고 즉시 의미를 알아챌 수 있어야 합니다.
6767

@@ -918,7 +918,7 @@ it("사이트 이름을 변경하면, 성공 결과값을 받아온다", async (
918918

919919
# 섹션 3️⃣: 프론트엔드 테스트
920920

921-
## ⚪ ️ 3.1. 기능으로부터 화면을 분리하십시오
921+
## ⚪ ️ 3.1 기능으로부터 화면을 분리하십시오
922922

923923
:white_check_mark: **이렇게 해라:** 컴포넌트 로직을 테스트할때, 화면의 세부사항들은 제외되어야할 노이즈가 됩니다. 그것을 제외함으로써 당신의 테스트들은 순수한 데이터에 집중할 수 있습니다. 실제로, 그래픽 구현에 너무 결합되지 않는 추상적인 방법을 통해 요구되어지는 데이터를 마크업으로부터 추출하십시오. 그리고 느리게 만드는 애니메이션들을 제외한 오직 순수한 데이터를 검증하십시오(vs HTML/CSS 화면 세부사항). 당신은 렌더링하는 것을 피하고 오직 화면의 뒷부분(서비스, 액션, 스토어등과 같은)만을 테스트 하려고 할 수도 있습니다. 하지만, 이것은 실제와 같지도 않으며 심지어 화면에 올바른 데이터가 도달하지 않은 경우를 나타내지도 않는 가짜 테스트에서의 결과가 될 것 입니다.
924924

@@ -1202,7 +1202,7 @@ test('movie title appears', async () => {
12021202

12031203
<br/>
12041204

1205-
## ⚪ ️ 3.5. 화면의 내용이 네트워크를 통해 어떻게 제공될지 확인하십시오
1205+
## ⚪ ️ 3.5 화면의 내용이 네트워크를 통해 어떻게 제공될지 확인하십시오
12061206

12071207
![](https://img.shields.io/badge/🔧%20Example%20using%20Google%20LightHouse-blue.svg
12081208
"Examples with Lighthouse")

‎readme.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -63,7 +63,7 @@ Guidelines for CI in the JS world (9 bullets)
6363

6464
<br/>
6565

66-
## ⚪️ 0. The Golden Rule: Design for lean testing
66+
## ⚪️ 0 The Golden Rule: Design for lean testing
6767

6868
:white_check_mark: **Do:**
6969
Testing code is not like production-code - design it to be dead-simple, short, abstraction-free, flat, delightful to work with, lean. One should look at a test and get the intent instantly.
@@ -895,7 +895,7 @@ it("When updating site name, get successful confirmation", async () => {
895895

896896
# Section 3️⃣: Frontend Testing
897897

898-
## ⚪ ️ 3.1. Separate UI from functionality
898+
## ⚪ ️ 3.1 Separate UI from functionality
899899

900900
:white_check_mark: **Do:** When focusing on testing component logic, UI details become a noise that should be extracted, so your tests can focus on pure data. Practically, extract the desired data from the markup in an abstract way that is not too coupled to the graphic implementation, assert only on pure data (vs HTML/CSS graphic details) and disable animations that slow down. You might get tempted to avoid rendering and test only the back part of the UI (e.g. services, actions, store) but this will result in fictional tests that don't resemble the reality and won't reveal cases where the right data doesn't even arrive in the UI
901901

@@ -1166,7 +1166,7 @@ test('movie title appears', async () => {
11661166

11671167
<br/>
11681168

1169-
## ⚪ ️ 3.5. Watch how the content is served over the network
1169+
## ⚪ ️ 3.5 Watch how the content is served over the network
11701170

11711171
![](https://img.shields.io/badge/🔧%20Example%20using%20Google%20LightHouse-blue.svg
11721172
"Examples with Lighthouse")

0 commit comments

Comments
(0)

AltStyle によって変換されたページ (->オリジナル) /