cypress入門

Cypressとは

Cypress はフロントエンドのE2E(End to End)テストツール

E2Eテストとは

  • E2E(End to End)は、端から端までの意味。
  • システム全体を通して正しく動くかを検証するためのテスト。
  • 人間が仕様書通りに動くか確認するテストも含まれる。

人力でのテストの課題

  • 工数がかかる。
  • 網羅性に欠ける

=> Cypressで自動化!コスト削減&品質向上!

E2E以外もテスト可能

Cypress v10リリース(2022-06-01)

Cypress v10では、cypressを立ち上げた時点で以下の2つから選択できる

  • E2E
  • コンポーネント

※ コンポーネントテストはのCypress v10からベータ版に昇格

cypressの特徴

特徴その1:mocha + chai ベースでテストを書くことができる

mocha.js

テスティングフレームワーク

  • テストの実行プログラムの作成
  • テスト結果の判定
  • 集計など

chai.js

アサーションライブラリー

プログラムの前提として満たされるべき条件を記述し、実行時にそれが満せてない場合にエラーや例外を発生させる機能

例)
テスト:AページでBボタンをクリックしてCコンポーネントが表示されること
アサーション:Cコンポーネントが表示されるかの判定

特徴その2:jQueryライクにかける

Cypressは、jQueryの強力なセレクタエンジンを活用している。

cy.get("#main-content")
.find(".article")
.children('a[href^="/static"]')
.click();

cypressインストール使うまで

$ yarn add -D cypress

package.jsonにCypressを起動するためのスクリプトを追加

"scripts": {
  //追加
  "start": "cypress open"
}
$ yarn start

ディレクトリ構成

cypress
– fixtures
テストで使用する静的データを管理するディレクトリ(json、image など)
– integration
テストを管理するディレクトリ
– suport
カスタムコマンド

※ v10と相違点あり

scssのディレクトリ構成

ディレクトリと用途

scss
global 必要箇所で@use "../global" as g;して使う
  ┃  ┣ _index.scss
  ┃  ┣ _variable.scss
┗ _mixin.scssfoundation 共通のデフォルト設定
  ┃  ┣ _index.scss
  ┃  ┣ _setting.scss コメント
  ┃  ┣ _sanitize.scss リセットスタイル
┗ _base.scss 共通のスタイル
layout 共通のページのレイアウト
  ┃  ┣ _index.scss
  ┃  ┣ _container.scss
  ┃  ┣ _header.scss
┗ _footer.scss  ┃
  ┣ component 共通モジュール
  ┃  ┣ _index.scss
  ┃  ┣ _button.scss
  ┃  ┗ _link.scss …
  ┃
  ┣ project ページ毎に固有のモジュール(他のページで使わない)
  ┃  ┣ top
┃  ┣ _index.scss
  ┃  ┃  ┣ _card.scss
  ┃  ┃  ┗ _profile.scss …
  ┃  ┃
  ┃  ページ名 …
  ┃
  utility helper的にさくっと使えるもの
  ┃  ┣ _index.scss
  ┃  ┣ _display.scss
  ┃  ┣ _margin.scss
  ┃  ┣ _padding.scss
  ┗ _typography.scss
  ┗ style.scss

FLOCSSのディレクトリ構成を参考にしました。
階層を深くしたくなかったので、component project utility は、object ディレクトリを使わずにroot直下に置きました。

また、object という読み込み様のディレクトリを作成しています。
変数など使いたいファイルで@use "../global" as g;して、globalを読み込んで、g.$variable@include g.mq(){}といった形で利用可能です。

Sassの@importが廃止

Sassの@importが2022年に廃止されます。来たる日に向けて、@importを@useに置き換えました。

EasySassだと@use, @forwordが使えない

トランスパイルには、VSCodeのExtentionsのEasySassを使っていたのですが、どうやらEasySassは、Node製ではないようで、うまくトランスパイルされません。
代わりに「DartJS Sass Compiler and Sass Watcher」というExtentionsに乗り換えました。

パーシャル編集時にも、自動でトランスパイルさせる

このままでは、パーシャル以外のscssファイルを保存した時にしかトランスパイルされません。実作業では、パーシャルのファイルを編集していくことになるので、パーシャルのファイルが保存された時にトランスパイルしたいです。
これは、以下のブログに記載されていた設定で実現できました。

【VSCode】Dart Sassが使える拡張機能 – DartJS Sass Compiler and Sass Watcherの使い方

試しにSass Watcherを使わずに作業したら、パーシャルファイルの保存時に、トランスパイルされました。(追記:2022.01.20)

dockerでWordPressの開発環境を構築したメモ

勉強がてら既存のWordPressサイトのローカル環境を構築したのでメモ。

条件

  • Docker Desktopインストール済み
  • 管理しているWordPressサイトがある

作業の流れ

  1. docker-compose.ymlの作成
  2. ボリュームの作成
    1. テーマ
    2. プラグイン
    3. 画像
  3. データベース初期値の設定
    1. sqlファイルの用意
    2. エクスポートしたSQLファイルを取り込む
    3. テーブル接頭辞の設定

最終的なファイル構成

mySite
 ┣ docker-compose.yml
 ┣ plugins
 ┃ ┣ plugin A
 ┃ ┣ plugin B
 ┃ plugin C
 ┣ themes
 ┃ ┣ mytheme
 ┃ ┗ mytheme-child
 ┣ uploads
 ┃ ┣ 2020
 ┃ ┗ 2021
 ┗ db_data
   ┗ initdb
     ┗ exported_data.sql

docker-composeのコマンド

コンテナの起動 docker-compose up -d
  • -d オプション:コンテナをバックグラウンドで起動させておくことが出来る
コンテナの再起動 docker-compose up -d
  • 更新したdocker-compose.ymlを反映させられる
コンテナの停止 docker-compose stop
  • コンテナは削除されずに残る
  • 再び起動してもDBのデータはそのまま保持される
停止したコンテナの起動 docker-compose start
コンテナの削除 docker-compose down
  • コンテナは削除される
  • 再び起動しても、以前のDBのデータは削除される(ボリューム{後述}を利用すれば削除されない)

docker-compose.ymlの作成

Docker Compose 概要

Compose とは、複数のコンテナを定義し実行する Docker アプリケーションのためのツールです。Compose においては YAML ファイルを使ってアプリケーションサービスの設定を行います。コマンドを1つ実行するだけで、設定内容に基づいたアプリケーションサービスの生成、起動を行います。

https://docs.docker.jp/compose/overview.html

docker-compose.ymlは、公式のものを編集して作成していきます。https://docs.docker.com/samples/wordpress/

上記サイトにあるコードをコピーして、mySiteディレクトリにdocker-compose.ymlを作成します。

version: "3.9"
    
services:
  db:
    image: mysql:5.7
    volumes:
      - db_data:/var/lib/mysql
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: somewordpress
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpress
    
  wordpress:
    depends_on:
      - db
    image: wordpress:latest
    volumes:
      - wordpress_data:/var/www/html
    ports:
      - "8000:80"
    restart: always
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpress
      WORDPRESS_DB_NAME: wordpress
volumes:
  db_data: {}
  wordpress_data: {}

ターミナルでmySiteディレクトリ に移動して、次のコマンドを実行しWordPressの環境を立ち上げます。

docker-compose up -d

http://localhost:8000/にアクセスするとWordPressの初期設定画面が表示されます。
画面に従って、WordPressの初期設定を完了させます。

ボリュームの作成

ボリュームとは、Docker コンテナーにおいて生成され利用されるデータを、永続的に保持する目的で利用される仕組みです。

https://matsuand.github.io/docs.docker.jp.onthefly/storage/volumes/

今回、既存サイトのローカル環境の構築ということなので、すでにWordPressで使っているテーマ、プラグイン、DBのデータをこのボリュームを使ってコンテナにマウントすることで、コンテナからアクセスできるようになります。

テーマ、プラグイン、画像のボリューム作成

docker-compose.ymlファイルの19行目のvolumesに以下を追加

      - ./themes:/var/www/html/wp-content/themes
      - ./plugins:/var/www/html/wp-content/plugins
      - ./uploads:/var/www/html/wp-content/uploads

mySiteディレクトリ の直下にthemes, pulugins, uploadsディレクトリを作成し、それぞれに既存サイトで使っているテーマ、プラグイン、画像を配置します。

コマンドラインで、次のコマンドを実行して、コンテナを再起動します。
編集したdocker-compose.ymlファイルの内容を取り込みます。

docker-compose up -d

WordPressの管理画面からテーマの編集ページにアクセスすると、themesディレクトリに配置したテーマが、プラグインの編集ページにアクセスすると、pluginsディレクトリに配置したプラグインが表示されます。
この時点で、画像もマウントされてますので、次に説明するデータベースのデータを読み込めば、表示されます。

データベース初期値の設定

既存サイトで投稿された記事、ページ、プラグインの設定などのデータを初期値としてmySQLコンテナに取り込みます。

新しいインスタンスの初期化

コンテナが初めて起動されると、指定された名前の新しいデータベースが作成され、提供された設定変数で初期化されます。さらに、/docker-entrypoint-initdb.d にある拡張子 .sh, .sql, .sql.gz のファイルがアルファベット順で実行されます。このディレクトリにSQLダンプをマウントすることで、簡単にmysqlサービスにデータを取り込むことができ、カスタムイメージにデータを提供することができます。SQLファイルはデフォルトでMYSQL_DATABASE変数で指定されたデータベースにインポートされます。

https://hub.docker.com/_/mysql/

sqlファイルの用意

まずは、既存サイトのデータをエクスポートします。今回は、phpMyAdminからエクスポートします。次のページを参考にエクスポートしてください。
WordPress Codex

エクスポート設定

  • エクスポート方法:「詳細」を選択
  • 生成オプション:「DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT / TRIGGER コマンドを追加する」オプションを選択

siteurl, homeの編集

エクスポートしたファイルのままだとoptionsテーブルのsiteurlとhomeが既存サイトのURLになっているので、サイトが表示されませんので、修正します。

エクスポートしたファイルをエディターで開いて、’siteurl’や’home’でファイル内を検索すると以下のような箇所がありますので、urlをhttp://localhost:8000に置き換えます。

(1, 'siteurl', 'https://hogehoge.jp/', 'yes'),
(37, 'home', 'https://hogehoge.jp/', 'yes'),

これで、SQLファイルの用意ができました。

エクスポートしたSQLファイルを取り込む

SQLファイルをSQLコンテナに取り込むには、/docker-entrypoint-initdb.dにSQLファイルをマウントします。

docker-compose.ymlファイルの6行目にあるvolumesに以下を追加します。

      - ./db_data/initdb:/docker-entrypoint-initdb.d

mySiteディレクトリ の直下にdb_dataディレクトリを作成し、用意したsqlファイルを配置します。

コマンドラインで次のコマンドを実行して再起動させます。

docker-compose down
docker volume rm $(docker volume ls -qf dangling=true)
docker-compose up -d

docker-compose up -dだけではなく、docker volume rm $(docker volume ls -qf dangling=true)で、ボリュームを一旦削除しています。そうしないと更新まえのボリュームを読み込んでしまい、sqlが読み込まれません。

参考記事:
https://qiita.com/kondo0602/items/ab0a85fb1e731234eb1a
https://qiita.com/t-kigi/items/82e36bcc7630f92fc24e

テーブル接頭辞の設定

既存サイトのWordPressのテーブル接頭辞がwp_でない場合、テーブル接頭辞の設定が必要です。

docker-compose.ymlファイルの28行目environmentに以下を追加します。(接頭辞をhoge_の場合)

      WORDPRESS_TABLE_PREFIX: hoge_

コマンドラインで、次のコマンドを実行して、コンテナを再起動します。

docker-compose up -d

http://localhost:8000/にアクセスすると既存サイトが表示されるはずです。

その他メモ

//使用していないDockerオブジェクトの削除
docker system prune
https://docs.docker.jp/config/pruning.html

//mySQLに入る
docker exec -it <コンテナ名> bash
※コンテナ名は、docker psで表示されるNAMESの値

// wordpressに入る
docker-compose exec <サービス名(wordpress)> sh
※サービス名は、docker-compose psで表示されるSERVICEの値

//データベース接続
mysql -u root -p

//データベース確認
show databases;

//データベース選択
use <データベース名>;

//テーブル確認
show tables;

プラグインを起動時にインストール(Dockerfile)(いつか書く)

参考:https://tech.recruit-mp.co.jp/infrastructure/post-11266/#h-5