Ruby
 Computer >> コンピューター >  >> プログラミング >> Ruby

RailsアプリをテストするためのDockerコンテナを設定する

Ruby / Rails開発者として、私たちはテストを書くのが大好きです。テストはソフトウェア開発の不可欠な部分です。優れたテストは、高品質のコードを書くのに役立ちます。これらは開発プロセス全体に付加価値をもたらしますが、テストを適切に管理しないと、速度が低下する可能性があります。不適切に管理されているテストの症状の一部を次に示します。

  • テストの実行には長い時間がかかります。
  • テストは信頼性が低く、ランダムに失敗します。
  • テストはマシンによって動作が異なります。
  • すべてのテストスイートを実行すると、CIの速度が低下します。

このブログ投稿では、コンテナを使用してテストの信頼性を高める方法について説明します。これは、高品質のソフトウェアを提供するのに役立ちます。

統合テストと単体テスト

コンテナーのトピックに飛び込む前に、まず、ユニットテストと統合テストの違いについて理解し、同じページにいるようにしましょう。

単体テストは、コードのブロックを分離してテストする方法です。これらは、コードブロックの機能をテストするのに役立ちますが、依存関係をテストするのには役立ちません。たとえば、簡単な方法は次のとおりです。

def sum(a, b)
  a + b
end

これは2つの数値を合計する関数であり、非常に単純です。この関数のテストは非常に簡単です。しかし、この関数が外部サービスに依存している場合はどうでしょうか。このメソッドは、合計が完了するとデータベースに書き込む必要があります。

  def sum!(a, b)
    c = a + b
    Sum.create(value: c)
  end

このコードブロックでは、値が追加され、データベースに保存されます。このコードブロックをテストするには、データベースサーバーを実行する必要があります。データベースサーバーを実行してこれをテストすると、単体テストではなくなります。これには外部依存関係が必要です。また、データベース接続と、レコードがデータベースに保存されているかどうかもテストします。この場合、このテストは統合テストです。

単体テストは単独の単体テストにすることができます (すべての依存関係をモック/スタブする)または社交的な単体テスト (他の依存関係との通信を許可します)。人々はユニットテストのさまざまな定義を提案しています。このブログのコンテキストでは、私たちが話している単体テストのタイプは、単独の単体テストです。

モックを使用して外部の依存関係を削除すると、テストの実行が速くなります。単体テストを使用している間、これらの依存関係は省略しますが、アプリケーションが期待どおりに機能することを確認するには、依存関係をテストすることも同様に重要です。データベース、ネットワーク呼び出し、ファイルなど、これらの外部依存関係をテストするために作成するテストは、統合テストです。 。

単体テストと同様に、人々は統合テストのさまざまな定義を提案しています。ただし、基本的な考え方は同じです。違いはスコープだけです。データベースに書き込む小さな関数は、統合テストになる可能性があります。システムの複数の部分を接続するより広範な機能も統合テストです。ここで話しているテストは、より狭い部分に焦点を当てています。テストが狭いほど、より多くのテストを作成する必要があります。ただし、より広範なテストでは、必要なテストの数は減少します。

統合テストの実行中は、アプリケーションと、データベースや外部サービスなどの依存関係を実行する必要があります。これらの依存関係の管理は難しい場合があります。

Dockerの基礎

Dockerは、アプリケーションをその環境(オペレーティングシステム)から抽象化し、ホストとは別に実行するのに役立つテクノロジーです。これは仮想マシンに似ていますが、より高速で効率的です。 Dockerを使用すると、アプリケーションコードとその依存関係を単一のコンテナーにパッケージ化できます。これにより、コードが移植可能になり、開発、テスト、本番環境で同じDockerイメージを実行できるようになります。これにより、アプリケーションが実行される環境の一貫性が保証されます。ホストサーバーに依存しないため、すべての環境でアプリケーションの動作を予測可能にします。 Dockerは、開発者がアプリケーションとその環境を実行および管理するのに役立ちます。これには、簡単なコマンドを使用したビルド、実行、デプロイ、更新が含まれます。

いくつかの重要な用語を理解しましょう:

  • Dockerfile -Dockerfileは、アプリケーションに必要な依存関係を定義する単なるファイルです。必要なオペレーティングシステム、データベースクライアントライブラリ、またはアプリケーションに必要なパッケージを指定できます。ここでは、アプリケーションの実行に必要なコマンドも定義します。 Dockerfileはベースイメージから始まります。これらのベースイメージは、オペレーティングシステムまたはプログラミング言語である可能性があります。

  • 画像 -画像は、コンテナの実行に必要な手順を示す青写真です。画像はさまざまなレイヤーで作成されます。 Dockerfileで定義されたすべてのステップは、イメージ内のレイヤーです。これにより、再利用性が向上し、中間レイヤーをキャッシュしてイメージをより高速に構築するのに役立ちます。

  • コンテナ -コンテナは実際の画像です。これらも停止状態になる可能性があります。コンテナーは、Dockerイメージから開始できます。 1つのDockerイメージで複数のDockerコンテナーを開始できます。コンテナは、イメージで指定された情報を保持します。アプリケーションの実行中に画像に加えられたすべての変更が保存される薄いコンテナレイヤーがあります。

  • Dockerの作成 --Docker Composeは、複数のコンテナーの管理に役立つ別のツールです。同じDockerイメージから複数のコンテナーを持つことができます。また、異なるDockerイメージからの複数のコンテナーが必要になる場合があり、これらのコンテナーは相互に作用する必要があります。 DockerComposeはコンテナーを管理します。利用できるツールは他にもありますが、このコンテキストでは、その単純さのためにDockerComposeのみを使用します。

仮想マシンはホストハイパーバイザーの上にあり、別のオペレーティングシステムをインストールする必要があるため、より多くのホストリソースが使用されます。ただし、Dockerを使用する場合は、ホストオペレーティングシステムにDockerエンジンをインストールするだけで済み、ホストリソースの管理はDockerによって行われます。 Dockerは、開発者とシスオペの両方の生活を楽にするのに役立つため、DevOpsカルチャーで非常に人気があります。

テストにDockerを使用する理由

Dockerは、最小限のリソース消費で、実行中のアプリケーションまたはテストをホスト環境から分離します。テストにdockerを使用する利点のいくつかを次に示します。

  • 軽量: Dockerコンテナは軽量です。これは、1つのテストプロセスが別のテストプロセスで問題を引き起こすことなく、複数のコンテナを同時に実行するのに役立ちます。

  • ポータブル: Dockerイメージは移植可能であり、どの環境でも実行できます。同じイメージを再利用してローカル環境とCI環境でテストを実行できるため、これはCIで役立ちます。

  • バージョン管理: 複数のアプリケーションを使用したり、依存関係をアップグレードしたりするには、ローカルマシンに異なるバージョンの依存関係が必要です。これは、Dockerなしで管理するのは非常に困難です。 Dockerを使用すると、さまざまなバージョンでさまざまなコンテナーを実行できます。さまざまなバージョンでテストを実行して、確認することもできます。

  • マイクロサービスの簡単な管理 :マイクロサービスでは、テストも分散されて複雑になります。これは、依存するマイクロサービスを管理する必要があることを意味します。 DockerとDockerComposeは、これらのサービスの依存関係を管理するのに役立ちます。

前提条件

これを試すには、次のように設定されていることを確認しましょう。

  • Docker
  • Docker-作成
  • Ruby 2.7(オプション、RubyをDockerコンテナーに追加しますが、テストには役立ちます)
  • レール(5.1以降を推奨)
アプリをDockerize

簡単なRailsアプリを作成し、それをコンテナー化することから始めましょう。私は新しいRailsアプリから始めています。既存のRailsアプリをコンテナ化することもできます。

rails new calculator

Dockerfileという名前のファイルを作成します 次の内容で:

FROM ruby:2.7
RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add -
RUN echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list
RUN apt-get update -qq && apt-get install -y nodejs yarn
RUN mkdir /calculator
WORKDIR /calculator
COPY Gemfile /calculator/Gemfile
COPY Gemfile.lock /calculator/Gemfile.lock
RUN bundle install
COPY package.json /calculator/package.json
COPY yarn.lock /calculator/yarn.lock
RUN yarn install --check-files
COPY . /calculator
EXPOSE 3000
CMD ["rails", "server", "-b", "0.0.0.0"]

定義したDockerfileにはRuby2.7ベースイメージがあります。 NodeJSとYarnが必要なので、次のステップはそれらをインストールすることです。インストールしたら、bundle installを実行します およびyarn install 。最後に、すべてのコードをコピーして、3000ポートをエクスポートしてRailsサーバーを実行します。これは非常に単純なDockerfileです。これにより、Railsアプリがドッキングされます。

これで、Dockerイメージを作成して実行し、実行されていることを確認できます。

Dockerイメージを作成します:

docker build . -t  calculator

コンテナを実行します:

docker run -p 3000:3000 calculator
計算ロジックを使用してモデルを作成する

計算ロジックを追加できる計算と呼ばれるモデルを作成しましょう。このモデルを使用して、いくつかのロジックとテストを記述します。 DockerComposeを使用してこれらのテストの依存関係を管理する方法を調べることができます。

現在、SQLiteでRailsを実行しています。 SQLiteではなくPostgresに変更しましょう。これは、次のコマンドで簡単に実行できます。

rails db:system:change --to=postgresql

計算モデルを生成します:

bundle exec rails generate model calculation

計算スキーマにいくつかのフィールドを追加します:

# db/migrate/create_calculation.rb

class CreateCalculations < ActiveRecord::Migration[6.0]
  def change
    create_table :calculations do |t|
      t.integer :x
      t.integer :y
      t.integer :result
      t.timestamps
    end
  end
end

次に、コンテナ内での移行をデータベースで実行してみましょう。

docker-compose exec web rails db:migrate

データベースはコンテナ内で実行されていないため、このコマンドを実行するとエラーがスローされます。

rake aborted!
PG::ConnectionBad: could not connect to server: No such file or directory
  Is the server running locally and accepting
  connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

Postgresイメージを別のイメージとして実行し、それらの間にネットワークを追加できます。このコンテナ通信を管理するために、DockerComposeを使用できます。

DockerComposeを使用した複数のコンテナーの管理

Railsアプリをコンテナ化すると、DockerComposeを使用してサービスに依存関係を追加できます。アプリケーションへの依存関係はPostgresです。

Postgres Dockerイメージは公開されているため、作成する必要はありません。ただし、データベースコンテナとRailsアプリコンテナを管理する必要があります。

version: "3.0"
services:
  db:
    image: postgres
    environment:
      POSTGRES_USER: calculator
      POSTGRES_PASSWORD: password
      POSTGRES_DB: calculator_test
  web:
    build: .
    ports:
      - "3000:3000"
    depends_on:
      - db
    environment:
      CALCULATOR_DATABASE_PASSWORD: password

次に、database.yamlに移動します ファイルを作成し、データベースを別のホストに変更します。ホストは、DockerComposeファイルのサービス内で指定された名前になります。この場合、ホストはdbです。 。 postgresでDBパスワードが同じであることを確認してください サービスとweb サービス。また、Docker Composeファイルで指定されているように、ユーザー名、パスワード、データベース名を変更します。

# database.yaml

development:
  <<: *default
  database: calculator_development
  username: calculator
  password: <%= ENV['CALCULATOR_DATABASE_PASSWORD'] %>

これで、次の1つのコマンドを使用してコンテナを起動できます。

docker-compose up

これにより、データベースとRailsサーバーの両方が起動します。これで移行コマンドを実行でき、Postgresに接続して移行を実行できるはずです。

テストの追加

すべてのセットアップの準備ができたので、モデル内に簡単なメソッドを記述して、メソッドをテストしましょう。

# calculation.rb

class Calculation < ApplicationRecord

  def self.sum(x, y)
    result = x + y
    Calculation.create(x: x, y: y, result: result)
    result
  end

end

このsumメソッドは、数値を加算するだけでなく、データベースに数値を保存します。したがって、このメソッドをテストするには、データベースインスタンスが実行されている必要があります。

データベースに接続する必要があるため、このテストは統合テストになります。

ミニテストを使用してテストを作成します。これはRailsのデフォルトです。

# calculation_test.rb

require 'test_helper'

class CalculationTest < ActiveSupport::TestCase
  test "should sum and save the data" do
    result = Calculation.sum(1, 2)
    c = Calculation.last
    assert result, 3
    assert c.result, result
  end
end

テストを実行します:

docker-compose exec web rails test

上記のテストでは、sumメソッドが値を加算してデータベースに値を保存しているかどうかをテストしています。 Docker Composeを使用すると、データベースに接続する非常に簡単な方法があります。

ここでは、メソッドはデータベースに依存しています。依存関係は、データベースだけでなく、RESTAPIを提供するサードパーティのサービスでもかまいません。それでは、sumを提供するサードパーティのサービスを使用してみましょう。 メソッド。独自に作成する代わりに使用できます。

# calculation.rb

class Calculation < ApplicationRecord

  def self.sum(x, y)
    # The hostname should be the same as it is specified in the docker-compose file
    url = 'https://sumservice:4010/sum'

    uri = URI(url)
    params = { :x => x, :y => y }
    uri.query = URI.encode_www_form(params)
    res = Net::HTTP.get_response(uri)
    throw "Error"  unless res.is_a?(Net::HTTPSuccess)
    result = res.body.to_i
    Calculation.create(x: x, y: y, result: result)
    result
  end

end

依存関係としてデータベースに対して行ったのと同様のことをRESTAPIに対して行うことができます。これらが有効なエンドポイントであることを確認する必要がありますが、テスト中に実際のサービスに電話をかけたくありません。この場合、モック/スタブテストを作成できますが、そうすると、これらのテストは統合テストにはなりません。テストが可能な限り現実的であることを確認したいと思います。この目的のために、コンテナで実行するモックAPIエンドポイントを作成し、モックコンテナAPIサービスを呼び出して、結果を返すことができます。

最初にテストを変更しましょう:

# calculation_test.rb

require 'test_helper'

class CalculationTest < ActiveSupport::TestCase
  test "should sum and save the data" do
    result = Calculation.sum(1, 2)
    c = Calculation.last
    #  we don't need this assetion as we are deligation this responsibility to external service:
    # assert result, 3 // Not needed
    assert c.result, result
  end
end

ここでは、sumAPIによって提供された結果がデータベースに適切に保存されているかどうかのみをテストするようにテストケースを変更しました。合計の実際の値が正しいかどうかをテストする必要はありません。これは外部サービスによって処理されるため、信頼できます。

モックサーバーを生成するには、openAPIを使用します。簡単なSwagger定義を作成しましょう:

ルートディレクトリに新しいフォルダを作成し、mockという名前を付けます 。フォルダ内に、ファイル名api.yamlを作成します

# api.yaml
swagger: "2.0"
info:
  description: "This is a sum api provider"
  version: "1.0.0"
  title: "API Provider"
host: "https://mock-service.com/"
basePath: "/api"
schemes:
  - "https"
  - "http"
paths:
  /sum:
    get:
      produces:
        - "application/json"
      parameters:
        - name: "x"
          in: "query"
          description: "x value"
          required: true
          type: "integer"
        - name: "y"
          in: "query"
          description: "y value"
          required: true
          type: "integer"
      responses:
        "200":
          description: "successful operation"
          schema:
            type: "integer"
            example: 3

仕様に基づいてこのサーバーを実行するには、任意のモックサービスプロバイダーを使用できます。プリズムというツールを使用します。 docker-composeファイルに追加できるdockerイメージが利用可能です:

version: "3.0"
services:
  db:
    image: postgres
    environment:
      POSTGRES_USER: calculator
      POSTGRES_PASSWORD: password
      POSTGRES_DB: calculator_test
  web:
    build: .
    ports:
      - "3000:3000"
    depends_on:
      - db
      - sumservice
    environment:
      CALCULATOR_DATABASE_PASSWORD: password
  sumservice:
    image: stoplight/prism:4
    command: mock -h 0.0.0.0 "/tmp/api.yaml"
    volumes:
      - ./mock:/tmp/
    ports:
      - 4010:4010
    init: true

それでは、テストを実行して、期待どおりに機能するかどうかを確認しましょう。

> docker-compose exec web rails test

Finished in 0.337710s, 2.9611 runs/s, 5.9222 assertions/s.
1 runs, 2 assertions, 0 failures, 0 errors, 0 skips

うん!これでテストが実行されました。このメソッドは、sumサービスのDockerイメージに接続して合計を取得し、Postgresに接続してデータを保存します。すべての依存関係はDockerComposeによって管理されるため、以前にインストールされた依存関係について心配する必要はありません。このテストを任意のマシンに移動すると、依存関係のインストールは必要ありません。マシンに必要なのはDockerだけです。

アプリケーションがRedisやMemcachedなどの他の依存関係に依存している場合、これらはdockerhubにあります。必要に応じて、これらのイメージをDockerComposeファイルに追加できます。

並列テスト

Rails 5.1.5+は、テストの並行実行をサポートしています。デフォルトでは、テストはプロセッサーの数に基づいてRails6から並行して実行されます。テストの実行中に、並列テストの数に基づいてデータベースインスタンスを作成します。 4つのプロセッサがある場合は、データベース「calculator_test-0」、calculator_test-1、calculator_test-2、およびcalculator_test-3が作成されます。 postgres cliに移動してデータベースを確認すると、次のように表示されます。

> \l
                                        List of databases
       Name        |   Owner    | Encoding |  Collate   |   Ctype    |     Access privileges
-------------------+------------+----------+------------+------------+---------------------------
 calculator_test   | calculator | UTF8     | en_US.utf8 | en_US.utf8 |
 calculator_test-0 | calculator | UTF8     | en_US.utf8 | en_US.utf8 |
 calculator_test-1 | calculator | UTF8     | en_US.utf8 | en_US.utf8 |
 calculator_test-2 | calculator | UTF8     | en_US.utf8 | en_US.utf8 |
 calculator_test-3 | calculator | UTF8     | en_US.utf8 | en_US.utf8 |

これで、Railsやミニテストを使用していない場合や古いバージョンのRailsを使用している場合でも、Dockerを使用してテストを作成すると、テストを並行して実行できます。 Railsは並列テスト用のデータベースを自動的に作成しますが、Redisやmemcachedなどの他の依存関係がある場合は、手動で管理する必要がある場合があります。

すべての依存関係が管理されているため、さまざまな引数を指定してDocker Composeを実行し、テストを並行して実行できます。この目的のために、テストを並行して実行するフォルダーを指定し、複数のDocker Composeファイルの作成を実行して、それらを並行して実行できます。

コマンドを簡略化するためのMakefileの追加

DockerおよびDockerComposeコマンドを使用してテストを実行しているため、コマンドは長くなります。日々の開発を行っている間、それらを覚えて実行するのは難しい場合があります。単純なコマンドに単純化するために、addMakefileを使用してみましょう。 Makefileは、ターゲットコマンドの実行を参照するために使用される単純なテキストファイルです。

.PHONY: test
up:
  docker-compose up
down:
  docker-compose down
test:
  docker-compose exec web rails test

makefileにいくつかのコマンドを追加しました。これは、アプリケーションの必要に応じて拡張できます。 Railsアプリケーションのルートディレクトリにmakefileを追加します。このmakefileを取得したら、次のコマンドを使用してテストを実行できます。

コンテナを起動します:

> make up

テストを実行します:

> make test
ローカル開発にDockerを使用する

アプリケーションの開発中にDockerを使用することもできます。これは、アプリケーションがテスト、開発、および本番環境で一貫して動作することを保証するのに役立ちます。上記のコンテナをローカル開発に使用するために変更する必要があるものを確認しましょう。

ボリュームマウント

アプリケーションをローカルで実行しているときに、コードに変更を加えたときに、アプリケーションにローカルサーバーの変更を反映させたいと考えています。現在のシナリオでは、コードがマシンからDockerにコピーされ、サーバーが起動します。そのため、ローカルマシンのファイルに変更を加えても、Dockerには反映されません。コードが常に同期していることを確認するために、ボリュームマウントを使用できます。

Docker Composeファイルで、ボリュームを追加しましょう:

version: "3.0"
services:
  db:
    image: postgres
    environment:
      POSTGRES_USER: calculator
      POSTGRES_PASSWORD: password
      POSTGRES_DB: calculator_test
  web:
    build: .
    volumes:
      - .:/calculator # Volume mounted
    ports:
      - "3000:3000"
    depends_on:
      - db
      - sumservice
    environment:
      CALCULATOR_DATABASE_PASSWORD: password
  sumservice:
    image: stoplight/prism:4
    command: mock -h 0.0.0.0 "/tmp/api.yaml"
    volumes:
      - ./mock:/tmp/
    ports:
      - 4010:4010
    init: true

これで、サーバーに何か変更を加えると、その変更が反映されます。コントローラを作成し、sumメソッドを呼び出してこれを試してみましょう:

# controllers/calculation_controller.rb
class CalculationController < ApplicationController
  def index
    result = Calculation.sum(params[:x], params[:y])
    render json: {result: result}
  end
end

ルートルートを追加します:

# routes.rb

Rails.application.routes.draw do
  # For details on the DSL available within this file, see https://guides.rubyonrails.org/routing.html
  root "calculation#index"
end

ここで、戻ってブラウザでアプリを確認すると、期待される応答が得られます。

RailsアプリをテストするためのDockerコンテナを設定する

模擬のsumserviceを使用してサーバーを起動していることに注意してください。 したがって、URLでクエリパラメータとして提供するものに関係なく、常に2が返されます。これは開発を行うための良い方法ではないようですが、モックサービスプロバイダーを使用することには利点があります。マイクロサービスを開発する場合、依存するサービスが多数存在する可能性があり、サービスを開始する前に起動する必要があります。これにより、開発中の生産性が向上します。私たちは他のサービスには関心がなく、私たちが開発しているサービスのみに関心があります。

実際のサービスでどのように機能するかを最終的に検証する場合は、新しいDocker Composeファイルを作成し、それをサービスの実際のイメージに置き換えることで確認できます。内部サービスの場合は、最新の安定したDockerイメージに置き換えるだけです。開発環境でも模擬サービスを利用することをお勧めします。

.dockerignore

アプリケーションが大きくなると、依存関係によってDockerビルドコンテキストが大きくなります。ビルドコンテキストが大きいほど、Dockerイメージのビルドに時間がかかります。ボリュームマウントでさえ、アプリケーションのサイズが大きくなると遅延が発生する可能性があります。この場合、不要なファイルを.dockerignoreに追加できます。 ビルドコンテキストを減らすためのファイル。

.git*
log/*
README.md
node_modules
エントリポイント

Railsサーバーがコンテナーで実行されているときに、コンテナーの終了時にPIDファイルが削除されなかったため、サーバーが既に実行されていることを示すエラーメッセージが表示されることがあります。このエラーを削除するには、ENTRYPOINTを追加して、server.pidを削除します。 ファイル。

FROM ruby:2.7
RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add -
RUN echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list
RUN apt-get update -qq && apt-get install -y nodejs yarn
RUN mkdir /calculator
WORKDIR /calculator
COPY Gemfile /calculator/Gemfile
COPY Gemfile.lock /calculator/Gemfile.lock
RUN bundle install
COPY package.json /calculator/package.json
COPY yarn.lock /calculator/yarn.lock
RUN yarn install --check-files
COPY . /calculator
EXPOSE 3000
ENTRYPOINT ./entrypoint.sh
CMD ["rails", "server", "-b", "0.0.0.0"]

entrypoint.shを作成します ファイル:

#!/bin/bash
set -e

# Remove a potentially pre-existing server.pid for Rails.
rm -f /calculator/tmp/pids/server.pid

# Exec the container's main process (CMD command in rails file)
exec "$@"

実行可能にする

chmod +x entrypoint.sh

これで、Dockerイメージを実行するときに、この問題は発生しません。

結論

統合テストと単体テストを区別することは非常に重要です。単体テストを作成しているときに、データベースなどの外部依存関係をモックすることができます。これは、コードを分離してテストするのに役立ちます。コアビジネスロジックとその依存関係の間で統合テストを実行することも同様に重要です。データベースや外部サービスなどの依存関係は、DockerとDockerComposeを使用して統合してテストできます。これら2つを分離することをお勧めします。それらを別々に実行できるはずです。単体テストを増やし、統合テストを減らすことで、テストをより速く、より確実に実行できます。

このワークフローのいくつかの利点は次のとおりです。

  • ユニットテストと統合テストの分離。
  • すべてのCIサービスはコンテナーで実行されるため、ローカルとCIで実行されるテストの動作は同じになります。これにより、ローカルマシンとCIサーバーでのテスト動作の一貫性を確保できます。
  • コンテナを使用してアプリケーションをデプロイすることも、本番サーバーの一貫性を確保するのに役立ちます。
  • 依存関係が適切に管理されているため、信頼性の高いテスト。
  • ポータブルテスト。複数の開発者が使用する場合、セットアップにほとんど労力は必要ありません。

  1. iOS 13 ダーク モード用にアプリを設定する方法

    Apple は、待望の iOS 13 アップデートを 9 月 19 日に、過去 4 年間 (iPhone 6s に遡る) 内に発売されたすべての iPhone でグローバルにリリースしました。 このアップデートの最大の機能の 1 つは、システム全体の iOS 13 ダーク モードでした。スマートフォンのディスプレイから放出される白色光によって引き起こされる眼精疲労に役立つことが期待されています. この機能は、Apple デバイスを使用する最終消費者にとっては喜ばしいことですが、iOS 開発者にとっては、iOS 13 ダーク モードに対応したアプリを準備する作業です。 iOS 13 ダーク

  2. Windows 10 でスマホ同期を設定して使用する方法

    Android および iOS のスマホ同期アプリと組み合わせて使用​​される Windows 10 のスマホ同期アプリは、Windows 10 PC でスマートフォンからの写真とテキスト メッセージを同期する唯一の方法です。 Windows 10 のスマホ同期アプリを使用すると、Windows 10 PC を離れることなく、テキスト メッセージを読んで応答したり、電話で写真を表示したりできます。スマホ同期アプリは、Windows 10 October 2018 Update 以降に既にインストールされているため、追加でダウンロードする必要はありません。 まず、スマートフォンを Window