Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。リスクベーステストのようなテスト技術は、何をテストして、いつテストを自動化するかを決めるのに役立つ。Bolboaca氏は主張する。Bolboaca氏は、すでに確立した製品をテストする時は、不具合が発生する部分で、より多くの自動テストを書くように提案する。2017において、様々な種類の自動テストについて話をした。InfoQは、このカンファレンスをQ&A、要約、記事で扱う。自動テストの目的というブログで、Bolboaca氏は受け入れテストの目的を定義する。受け入れテストは、通常、テスタが書き、システムの特定の機能を検証します。おかしなことに、大抵の人は、自動テストについて話す時に、受け入れテストだけに言及します。受け入れテストは、モジュールレベル、モジュール間、システムレベル、システム間等で実施できます。モジュール間やシステム間(2つよりも多くのモジュールに注目している)の受け入れテストがある場合は、それは総合的なテストです。別のモジュールの上にあるGUIを通して、ふるまいにアクセスするテストは、総合的なテストです。このようなテストは安定性を欠き、GUIに依存します。これらは望ましいものではありません。これらのテストは、第一に、製品担当者やスポンサー、第二に、テスタ、やっと第三に、技術チームの興味を引きます。Bolboaca氏に話を聞いた。Bolboaca氏:1つのテストは、はっきりと分かるものでなければなりません。テストの名前とその内容に始まり、なぜそのテストが必要か、どのように役に立つか、存在する目的は何かを、誰でも理解できるようにすべきです。このような理由で、受け入れテストは、短く、理想を言えば、技術的な言葉を含まないようにしましょう。「exception」という変数を使う代わりに、「error」という変数を使った方がよいでしょう。小さな、独立したテストを持つことで、問題がどこで起きたかを見つけるのに役立ちます。そのためには、1つのふるまいだけに注目した、小さく、原子的なテストを書く必要があります。1つのテストで、多くのふるまいをテストした場合、それは、ユニットテストではありません。それは、結合テスト、受け入れテスト、総合的なテスト、エンドツーエンドテスト、または、他のタイプのテストになります。よいユニットテストは、最小1つ、最大1つの検証をすべきです。InfoQ:総合的なテストと、受け入れテストやエンドツーエンドテストの違いは何でしょうか?Bolboaca氏:まず、エンドツーエンドテストについて答えましょう。エンドツーエンドテストは、システムのより多くのモジュールが、一緒にうまく動作するかどうかを確認することを意図しています。このテストは、モジュールの小さなふるまいに注目してはいけません。技術的なテストであり、設定、セキュリティ設定、データベース接続、ウェブサイトへのリンク等が正しいかどうかを知るのに役立ちます。エンドツーエンドテストを見るのは、技術チームです。受け入れテストは、機能に注目していて、主に、製品関係の人たちが見ます。これらのテストは、機能がうまく動くことを示す必要があります。製品関係の人たちは、機能を製品に配置する前に、受け入れるか、受け入れないかを判断するのに、これらのテストを利用します。受け入れテストはモジュールレベルで、複数のモジュールを通してもよく、また、システムレベルでもかまいません。それは、何を受け入れたいか、アーキテクチャがどのようになっているかによります。受け入れテストが大きくなればなるほど、メンテナンスするのは難しくなります。受け入れテストを持つコストは、そのサイズによって増加します。受け入れテストはモジュールに注目し、エンドツーエンドテストは一緒にうまく動作するかを見るために利用することをお勧めします。総合的なテストは、2つ以上のモジュールを通り、より多くのモジュールの中の、小さなふるまいを確認するために使われます。総合的なテストは最悪です。変更が多く、各モジュールの小さなこと1つ1つに依存するからです。多くのモジュールがあって、各モジュールに、確認しなければならないふるまいがいくつかあると考えてみましょう。総合的なテストですべてのふるまいを確認したい場合、1つのふるまいを変更した時に、残りのふるまいは変更しないようにする必要があります。総合的なテストが必要です。これらのテストは、GUIや、実際のデータベースやシステムを使うから、動作も遅くなります。1つのアプローチは、モジュール毎に受け入れテストを分離し、構成、「くっつけたもの」が正しいことを確認するために、いくつかのエンドツーエンドテストを書くことです。エンドツーエンドテストになります。ポジティブテスト、ネガティブテストのような技術を使いましょう。ユーザーがここで何をする必要があるのかという、ポジティブテストに最初に注目することは重要です。それから、うまくいかなくなることは何かというネガティブテストに注目します。2番目のステップは、これらのテストのリストを作ることです。私がお勧めする、3番目のステップはリスク分析をすることです。リスクとその影響の2つの軸で、各テストに目的を与えましょう。大きなリスクと強い衝撃を与えるものは、自動化する必要があります。このような場合にとても役に立つ、リスクベーステストについて、さらに学ぶとよいでしょう。それから、4番目のステップは、テストを選んで自動化を始めます。テストは、小さくて、はっきりとしていて、ビジネスドメイン言語に注目したものしましょう。あなたがユーザーで、それらのテストを読んだ時に、理解できるかどうか想像してみましょう。5番目のステップは、同僚のテスタ、アナリスト、プログラマ、製品関係の人たちにレビューしてもらいます。いつテストが十分になるかを知るのは、いつもバランスが難しいものです。重要なテストを忘れたり、余分なテストを追加したりすることがあります。そのような場合に、レビューのプロセスによりバランスをとることができます。2つの頭は1つよりもよいという原則をいつも使いましょう。チームは自分よりも賢いのです。InfoQ:テストを自動化することを決めるために、どの基準を使いますか?Bolboaca氏:先程言ったように、何を自動化するべきかを決めるのに、リスクベーステストをお勧めします。他にもいろいろあります。それならば、どのテストが必要で、それらのテストがどのように役立つのかを理解するまで、おそらくそれほど自動化する必要はありません。それが分かったら、以前の機能のテストを増やし、新しい機能はそのペースを維持する必要があります。2-5カ月で、チームがどこで間違い、リスクは何かについて、よく分かるようになるでしょう。それならば、過去からの知識を使い、どこで不具合が現れ、なぜそれが起こるかを見て、その分野で自動テストをより多く書きましょう。数個の自動テストを書きましょう。最初に間違えるのは分かっていますから。:)InfoQ:実行可能な仕様を作成するために、どのようにテストの自動化を適用しますか?Bolboaca氏:第一に、テストは、技術的な言語ではなく、ドメイン特化言語を使うべきです。テストの名前は、製品関係の人たちや顧客が理解できるものにしましょう。第二に、様々なグループの人たちが理解できるように、テストを分類する必要があります。そのため、1つのパッケージにユニットテスト、もう1つのパッケージに結合テスト、また別のパッケージに受け入れテストを分類します。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。