allure reportでテストの歴史を感じたかい？(Gitlab)

マリーザ？！

テストの履歴を見るとどんだけ連続で成功したり失敗したりしてるかわかります

わかると何がいいかって、E2Eだと特にそうなんだけど、不安定ないわゆるFreakyなテストを見つけられます

以下typescript+npm+playwright+Gitlab前提

playwrightでAllureログを出すようにする

www.npmjs.com

Allure用のプラグインがあるので、それで出力できる。

Installation

npm i -D @playwright/test allure-playwright

手元ならHTMLレポーターもいるだろうからplaywright.config.tsは以下

{
  reporter: [["html"], ["allure-playwright"]];
}

これで playwright testするとallure-resultsディレクトリの生成とそんなかへの出力がされるようになる

歴史を話すと昔のPlaywrightのレポートの標準だったとか何とか。本当か怪しい。ただ公式ドキュメントでも言及されてたり充実してるのは確か。

履歴を持つAllure Reportの生成

allurereport.org

前に生成したallure-report/historyをテスト実行時にできる allure-resultsにぶち込んで allure generate

CIというかスクリプト的にはmv書き込んでおけば良い

Gitlabで利用する

medium.com

上記のyamlを用法容量を守ってパクるんだけど、コロンが二つ連続してたり文法エラーあるんでそこは気をつける、気をつけた。

最近はmasterじゃなくてmainで作られるとかもあるのでそこも対応。

上のmediumにもあるけど${CI_DEPLOY_TOKEN}は適宜Gitlabの設定→アクセストークンから作って環境変数とかに突っ込む事。Gitlabのセキュリティの問題。公開ならいらんらしいけど、公開でもあっても邪魔にならんし作っといていいんじゃないかな

stages:
  - test
  - allure
  - deploy

.download_history: &download_history
  after_script:
    - apt-get update
    - apt-get upgrade -y
    - apt-get install -y unzip
    - mkdir backup && cd backup || true
    - "curl --location --output report.zip --request GET \"https://gitlab.com/api/v4/projects/${CI_PROJECT_ID}/jobs/artifacts/main/download?job=pages\" --header \"Authorization: Bearer ${CI_DEPLOY_TOKEN}\" || true"
    - (unzip report.zip) || true
    - cd ../
    - (cp -r backup/public/history/ allure-results/history) || true

.test_template: &test_template
  allow_failure: true
  stage: test
  image: mcr.microsoft.com/playwright:v1.40.1-jammy
  script:
    - npm install @playwright/test
    - npx playwright test
  artifacts:
    when: always
    paths:
      - allure-results/
    reports:
      junit: results.xml

smoke:
  <<: *test_template
  <<: *download_history

allure_report:
  stage: allure
  when: always
  image: timbru31/java-node
  dependencies: 
    - smoke
  script:
    - npm install
    - npx allure generate #change allure command specific to your framework
  artifacts:
    when: always
    paths:
      - allure-report/
      - allure-results/
  only:
    - main
  
pages:
  stage: deploy
  when: always
  dependencies:
    - allure_report
  script:
    - mv allure-report/ public/
  artifacts:
    paths:
      - public
    expire_in: 30 days
  only:
    - main

.download_historyで以前のhistoryを取得する

前回test_templateでArtifactsに保存したallure-resultsを拾う部分。拾い方の部分ドキュメント読んでないからようわからんけど雰囲気わかるはず

apt-get update周りは過剰かもしれない、調べてない。

CI_PROJECT_IDはGitlabが設定するからコピペでいいけど、CI_DEPLOY_TOKENは上でも書いた通り自分で環境変数として作る必要がある。名前変えたらもちろん合わせる事。

いちいち || trueしてるのは初回実行とかで拾えなかった時パイプラインを失敗としないため。本当は拾えてほしい時もエラーにならない問題はある。

test_templateはいい感じに

各テスト実行の通り

allure_reportでreports,resultsをArtifactsで保存

pagesが使う分にはreportsでいいけどresultsが次回実行の時にいる

pagesは名前固定

public にhtml保存すりゃいいっぽい。report持っていく

junt xmlでテストレポートを保存して履歴とって閲覧する-Gitlab編

自動テストのレポートのデファクトと言ったらjunit reportなんですよ

すごいよね。いまだにjunit xmlがスタンダード。何年現役なんでしょう。多くのciでもこいつをいい感じに見せるビューを備えてる

Gitlab

docs.gitlab.com

junit xmlの出力

playwright.dev

playwright.config.tsのdefineConfig.reporter:Arrayに'junit',{outputFile: 'results.xml'}突っ込むか、npx playwright test --reporter=junitするか

個人的に設定に書いちゃうのが多いので今回はその例でやる。好み

htmlは個人的に追加でだしてるだけなんでいらんかったら無視で良し

export default defineConfig({
// other setteings
  reporter: [['junit', { outputFile: 'results.xml' }],["html"]],
// other setteings...

gitlab-ci.yml

artifacts以下が重要。reports書けば各パイプラインのtestsタブにレポートが出るようになる

junit xmlのパスって何？って人はさっきdefineConfigやらに書いたoutputFileやそのあたりにあるファイルを探してください

stages:
  - test

tests:
  stage: test
  image: mcr.microsoft.com/playwright:v1.39.0-jammy
  script:
    - npm install @playwright/test
    - npx playwright test
  artifacts:
    reports:
      junit: results.xml

出力

おまけ mcr.microsoft.com/playwright:v1.39.0-jammy

hub.docker.com

Microsoftって書いてあるけどおもっきしUbuntuイメージ。playwright公式かつmicrosoft公式。

playwrightとブラウザがインストールされたdockerイメージ。npx playwright installとか省略してるのはこれのおかげ。便利。

cypressのチュートリアルの実践

cypressのチュートリアルどこまでできるか

結論から言うと以下ができる

• scaffoldでサンプルプロジェクトを作る
• サンプルプロジェクトを実行して自動テストが動くさまをみれる(ローカル実行)
• サンプルプロジェクトをcypress cloudを利用してレンタル遠くの実行環境で動かせる(リモート実行)
• サンプルプロジェクトを好みのci使って構築実行できる
  • 今回はcircle ci

参考記事

公式のget start

docs.cypress.io

あとはcypress openしたものをcontinue

scaffold

npx cypress open するとウィザードが出てポチポチしてたらプロジェクトができてておったまげる

しかもこのウィザードからテスト選ぶと画面の変化の様子とコードを照らし合わせながら実行できたりしてあまりにも便利。すごすぎ

cypress.io内のテスト実行用のサイトで動かしてくれるのでいろいろ安心

テストケースが175くらいあってサンプルとしては優秀なんだけど、後述のcypress cloudとかに使うと一気に無償枠の500を消費するから減らしとくといい

いろいろContinueとかしてたらcypress cloudというレンタル実行環境を使わしてくれる。browser stackみたいなもん。学習の範囲なら無償で賄えると思うのでどうせならやってみるといい。ただテストケースは減らしといたほうがいいかも

サンプルを少し見る

いつものと特徴的なコードを見ておきます。

共通beforeEach

describe('example to-do app', () => {
  beforeEach(() => {
    // Cypress starts out with a blank slate for each test
    // so we must tell it to visit our website with the `cy.visit()` command.
    // Since we want to visit the same URL at the start of all our tests,
    // we include it in our beforeEach function so that it runs before each test
    cy.visit('https://example.cypress.io/todo')
  })

テストページを開く一般的な方法。大体想像通りだけど、visitはSelenideのopenやplaywrightのgotoとかと同義だけどちょっと違うように、なんでかみんなここで個性出すから、ちゃんと抑えときたい。

1-getting-started\todo.cy.js

いつもの。CSS Pathでアクセスするgetのやつとshouldやclickみたいなよくあるやつ。眺めておきたい

    it('can filter for uncompleted tasks', () => {
      // We'll click on the "active" button in order to
      // display only incomplete items
      cy.contains('Active').click()

      // After filtering, we can assert that there is only the one
      // incomplete item in the list.
      cy.get('.todo-list li')
        .should('have.length', 1)
        .first()
        .should('have.text', 'Walk the dog')

      // For good measure, let's also assert that the task we checked off
      // does not exist on the page.
      cy.contains('Pay electric bill').should('not.exist')
    })

2-advanced-examples\actions.cy.js

clickとか基本的な操作。眺めておきましょ。あと以下のページを覚え解くこと

on.cypress.io

2-advanced-examples\connectors.cy.js

eachみたいな便利系がそろっている。

  it('.each() - iterate over an array of elements', () => {
    // https://on.cypress.io/each
    cy.get('.connectors-each-ul>li')
      .each(($el, index, $list) => {
        console.log($el, index, $list)
      })
  })

example.cypress.io

2-advanced-examples\aliasing.cy.js

Cypressの罠ともいえるポイントを押さえたコード

以下はよくないらしい。Cypressのコマンドは基本非同期で、以下は想定通りに動作しない可能性があるとのこと。

// this won't work the way you think it does
const button = cy.get('button')
const form = cy.get('form')

button.click()

いろいろ試したけど具体的にどういうタイミングでおかしくなるかよくわからない・・・

こうなるとアクセサの再利用どうなるの的な話あって、それの回答になるのがalias機能、Chainable#asメソッド

  it('.as() - alias a DOM element for later use', () => {
    // https://on.cypress.io/as

    // Alias a DOM element for use later
    // We don't have to traverse to the element
    // later in our code, we reference it with @

    cy.get('.as-table').find('tbody>tr')
      .first().find('td').first()
      .find('button').as('firstBtn')

    // when we reference the alias, we place an
    // @ in front of its name
    cy.get('@firstBtn').click()

    cy.get('@firstBtn')
      .should('have.class', 'btn-success')
      .and('contain', 'Changed')
  })

as("@name")でコンテキストに保存してcy.get("@name")で取得する形

コンテキストが共有される範囲や寿命は調べ切ってないけど、Mochaのコンテキストを利用しているらしくそれに準拠してる様子。

ちゃんと調べてないから大きいことは言えないけど、以下のコードで大まかなイメージがつくと思う。

describe('parent', () => {
  beforeEach(() => {
    cy.wrap('one').as('a')
  })

  context('child', () => {
    beforeEach(() => {
      cy.wrap('two').as('b')
    })

    describe('grandchild', () => {
      beforeEach(() => {
        cy.wrap('three').as('c')
      })

      it('can access all aliases as properties', function () {
        expect(this.a).to.eq('one') // true
        expect(this.b).to.eq('two') // true
        expect(this.c).to.eq('three') // true
      })
    })
  })
})

ただaliasした要素はいつのものなのか、aliasした後に要素に変化あったらどうなるのかはよくわからない。使うなら調査。

詳細は以下。読んでおきましょう。

docs.cypress.io

cypress cloud

レンタル実行環境。テスト実行用のPCとブラウザのセットがテスト実行のため、時だけ借りられる。

cypress専用のbrowser stackと考えてよい。デフォルトでfree planが使えて月に500ケース実行の権利がついてくる。余談だけど75$のTeamプランで10000ケースになってテスト結果の保持期間が30日から90日になるらしい。

Cypress専用なだけあってUIがいかしてる。Overciewの情報量が多くて適切

各テストの実行時間といった実行時のメタ情報に加えて、前後の結果やバージョン管理のどのコミットか、さらにはテストコードまで見られるので、Cypressコードの解析まで含めた実行環境としてはかなりのハイクオリティ。録画すれば実行時の動画もみられる様子。すげー

テスト結果分析のダッシュボードとして優秀。だけど実行回数の制限が絶妙にきつい。チュートリアルの実践という意味からそれて実行計画考えると、テストケース小さく作るとすぐ食いつぶすし頻度もデイリーだと17件とかしかできない。プッシュタイミングとかやるとすぐ食いつぶすだろうからマージタイミングとかでやることになるかもだけど個人でわざわざみたいな話になる。アクティブなプロジェクトに対して週末プログラミングのお供で使うくらいがいいのかな。Teamプランだとデイリー340くらい。複数プロジェクトで使うとどうなんだろうという数字。

circle ci

注意点

• Organization settingのsecurityでサードパーティorbの許可を出す
• Project SettingでEnvironment Variable にCYPRESS_RECORD_KEYを設定する
• CypressのScaffoldコード使うならconfig.ymlのnpm startは該当コードないので消しとく

config.ymlはポチポチしてたら出てきたサンプルから自分のアプリ起動用のnpm startを消した形。以下の通り

version: 2.1
# Uses the official Cypress Orb
# https://circleci.com/developer/orbs/orb/cypress-io/cypress
orbs:
  cypress: cypress-io/cypress@3
workflows:
  build:
    jobs:
      - cypress/run:
          # For recording and parallelization to work you must set your CYPRESS_RECORD_KEY
          # in CircleCI → Project Settings → Environment Variables
          # Records in parallel to Cypress Cloud 
          # https://docs.cypress.io/guides/guides/parallelization
          parallelism: 2 # Uses 2 parallel instances
          # Starts web server for E2E tests - replace with your own server invocation
          # https://docs.cypress.io/guides/continuous-integration/introduction#Boot-your-server
          cypress-command: 'npx cypress run --record --parallel'

めんどいからコメント残してるけど要はnpx cypress run セットアップは案内されたorb何も考えず使ってるのでようわからん。変なもんじゃ無さげだし

Cypress Cloudにも結果が乗るけどCircle CI側のクレジットが増えてるし結果流れただけで流石にCircle CI側のインスタンス使ってるはず

Cypress CloudのUsage & BillingみるとAdditionalあるのが心臓に悪いんだけど流石にこれ請求外であってるんだろうか。上の円グラフは増えてないしそう思いたい。怖い

後日見たらしっかり上限突破してました、ダメじゃねえか。Circle CIのクレジット何で減ってんだよ。

You've reached 124% of your test results for this usage period. Parallelization has been disabled and run details will be hidden. To re-enable parallelization and to see new runs, you can upgrade your plan or wait until your usage period resets.

らしくて、どうやら結果詳細は見れないし並列化も無効になるよ。とのこと。請求ない様子で一安心だけどこのプロジェクトは停止だわ。両方の費用消耗するなら流石に効率悪すぎね？連携する意義ある？

Circle CIで実行したときの結果をCypress Cloudのダッシュボードで見るとparallelism: 2が効いててちゃんと2並列で動いてるっぽい。

Circle CI連携のRunのOverviewのTests for reviewは空になった。なんで？地味に画面上部にcircle ci側のworkflowのIDが表示されて、それのWebページへのリンクになっている

頭のほうに箇条書きしたけど、Circle CI側でorb許可やEnvironment ValiableへのCYPRESS_RECORD_KEYの設定は行っておくこと

モダンな開発環境、CIを整えてかっこいいテスト結果確認ダッシュボードまで構築できるんで結構楽しいチュートリアル。学べるものも以下の通り多い。

• Cypressのサンプルコードの入手方法
• Cypressによるテストプロジェクトの構築
• Cypressによるテスト実行
  • ローカル
  • Cypress Cloudによるリモート
• Circle CIでCypressのテストを実行する方法
  • config.ymlの書き方

が、Cypress Cloud周りが罠

• Free Planを食いつぶす
  • サンプルケース175ほどに対してFree Plan上限500なんで3回リトライしたらおわる
• Circle CI連携がほぼ無意味
  • 両方のクレジットを消費する
  • 二重にコストをかけて、結果を両方で見られるだけ

リスクを把握して楽しくチュートリアル

パラレボCSP研究

パラレボ攻略で調べるとDPばっか出てくる

譜面

http://eba502.web.fc2.com/fumen/ddr/x3/pararevo_4s.html

↑軸

クソ早軸乱打。360の8分

↓左足入り

１２３４５６７８１２３４５６７８１２

↓↑→↑↓↑←↑↓↑→↑↓↑←↑→↑

ＬＲＬＲＬＲＬＲＬＲＬＲＬＲＬＲＬＲ

↑軸抜け後

クソ複雑乱打。左足入り交互を意識して完全に覚える。

実は交互に踏む配置だけど逆足めっちゃあったりいきなりスライドになったりと。足順や体の向きが複雑。むちゃくちゃだろ。なんだよ逆足からのRRスライドって。わかるわけがない

入り Ｌ←-Ｌ→(逆足)-Ｒ→-Ｌ←-Ｒ↑-Ｒ→-Ｌ←-Ｒ→-Ｌ←

数 4-5-5-5-12-5-5-5-5

←左足入り　捻りむずいところ強調。スライドにすべきかも

３４５６７８１２３４５６７８１２３４５６７８１２３４５６７８１２３４５６７８１２３４５６７８ ←→↓←□→↑→←↓□→↑←↑→□←↓→↓←□↑←↓↑→↓→↑←→↓←□→↑←↑→□←↓↑→↑□→↓←→↑□←↓→↓←□

交互

ＬＲＬＲ□LＲＬＲＬ□ＲＬＲＬＲ□ＬＲＬＲＬ□ＲＬＲＬＲＬＲＬＲＬＲＬ□ＲＬＲＬＲ□ＬＲＬＲＬ□ＲＬＲＬＲ□ＬＲＬＲＬ□

スライド

ＬＲＬＲ□ＲＬＬＲＬ□ＲＬＲＬＲ□ＬＲＬＲＬ□ＲＬＲＬＲＬＲＬＬＲＲＬ□ＲＬＲＬＲ□ＬＲＬＲＬ□ＲＬＲＬＲ□ＬＲＬＲＬ□

どっちもどっち

↓スイッチ連打

スイッチできればいいけど出来ないので気合で正面向いて踏みまくる。

次は低速と低速抜けを研究

文書作成ワークスペース

マークダウンで原稿を書くことがあります。仕事用の

その時に作ってるワークスペースの内容機能目的実現方法書いていく

このブログは仕事のブログネタとして利用されます

目的はマークダウンで快適に書いて色んな形式で提出

求める機能は以下

• 構造化
  • 項目ごとにフォルダやファイルを作れる
  • 製本に含まない付録や資料を保存できる
• レビュー
  • レビューしたい場所、内容をメモできる
  • レビューしたいポイントを一覧化出来る
• 製本
  • マークダウン
  • その他なんか

やりたいファイル構造

├─1.intro
│      1.hello.md
│      2.motivation.md
│
├─2.about
│      1.notice.md
│
├─3.main
│      1.wao.md
│      2.amaging.md
│      3.foo.md
│
└─4.fin
        1.bye.md

目次からこの構造のディレクトリやファイルを生成するようなスクリプト用意しても良いかもしれない

ファイル名をナンバリングしておくと後の製本とかシンプルに構造を見る時に役立つので意識しておくとよい

ReviewMeでレビューポイントをメモ(ReviewMe)

レビューしたい場所のメモ手段のため、//ReviewMe レビューして欲しい事 みたいなフォーマットでメモしてる

仕事用のブログは語調を適当にするとあかんのがめんどい
//ReviewMe こんな語調で良い？

後の適当grep で拾うためのマークなので、別に//ReviewMeという単語である意味はない。ぱっと見分かりやすいし他の単語と被って拾いすぎたり拾えなかったりがないためこれでマークしてる

レビューポイントの一覧化(適当greg)

grep -r -n ReviewMe ./

出力例

./1.intro/1.hello.md:1:// ReviewMe:気の利いた挨拶
./2.about/1.notice.md:4:// ReviewMe:いい感じに注意
./3.main/2.amaging.md:2:// ReviewMe 感動的すぎないか？
./3.main/2.amaging.md:7:// ReviewMe もっと感動的すぎないか？
./3.main/3.foo.md:1:// ReviewMe barbaz

割とこれでいける。欲を言えばファイル変わった時空行入れるとかやった方が見やすい。けどそんな多くないことが多いしちゃんとレビューポイント拾えてるか確認するため結局ファイルの内容見てるから今のところ手動でやってる

awk で頑張るとかすれば良いけど今後のアップデート

マージリクエストでレビューもらう

ワークスペースというよりワークフローの話

GitlabのMRのコードレビュー機能で見たりレビューしたり。エンジニアにとってのいつもの手順でレビューしてる。Gitlabのレビュー機能はIssue即建てられたりそこからMR作ってブランチ作ってあと作業するだけまでできたりで有能すぎるんよ

この時レビューサマリー出して渡しとくと話が早くて良い

対面で見ながらでも良いし、非同期で見てもらっても良い

製本(catやPandoc)

簡単にやるだけならcat連結

mkdir -p dist
rm dist/*

ls 1.intro/* | xargs cat >> dist/1.intro.md
ls 2.about/* | xargs cat >> dist/2.about.md
ls 3.main/* | xargs cat >> dist/3.main.md
ls 4.fin/* | xargs cat >> dist/4.fin.md

cat dist/*.md >> dist/readme.md

ブログ記事としての提出が多いから全連結して1ファイルで送れるようにすれば良いかな状態。フォルダ単位とか指定フォルダのみとかで章別mdファイルでもやれると良いのかな感はある。利用シナリオ思いつかないけど。全連結で良くない？

途中1.introとか章別でも連結してるけどいらん説深い。

Makefile書いておくとエンジニアフレンドリー。今Windowsでもshバリバリ使う感じだから各ツールやスクリプトはshで良いんじゃね精神。WSLやgitbash常用してるでしょ。

Pandocでいろんな形に対応する事もできるけど需要が今んとこないんで今後のアップデートで実装されて欲しい。

これを適当にGitlabとかに突っ込んでコピーかフォークかわからんけどやって使うようにしたい。ハイパーローカル管理状態

大君の末裔

ハイモアが無難かなー

テンニンカはS2

スキルを身につけてプログラマー転職！

募集要項「n年以上の実務経験」

実務経験書いてなく実際要求しないのもあるっちゃあるけど、そういう職場でやっていくモチベーションがハイレベル説ありますね

先に求人見た方が良くない？不幸生まれてない？