Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。(株)チェンジビジョン原文(投稿日:2017/01/19)へのリンクテストを小さくする。プログラマとテストがペアになる。Bolboaca氏からの提案だ。ユニットテストは、プログラミングとテストが混ざり合ったものだ。プログラマは、テスタと共に作業することで、お互いに学び合い、視野を広げることができる。2017において、様々なタイプの自動テストについて話す予定だ。InfoQは、このカンファレンスについて、Q&A、要約、記事で扱う。[ヨーロッパテストカンファレンス]は、専門家や実践者が一緒に話し、学び、テスト技術を実践するところです。私たちは、テストをもっと効果的にするために、先進的な新しい方法を詳しく調べ、より強いコミュニティに成長する基本的な方法を十分に理解するようにします。自動テストの目的というブログの中で、Bolboaca氏は、ユニットテストがすべきことを定義している。ユニットテストは、1つのメソッドかクラスに注目します。ユニットテストは、とても小さいもので、多くても数行のコードにすべきです。ユニットテストを書いている時に、間違えはいくらでも起こり得るので、これは取るに足りないことではありません。ユニットテストは小さいので、メモリで実行すべきであり、数ミリ秒で動かなければなりません。外部依存(データベース、ウェブサービス、ファイルシステム、I/O)のあるテストは、ユニットテストではなく、別のもの(結合テスト、総合的なテスト、受け入れテスト、エンドツーエンドテスト等)です。InfoQは、よいユニットテストを書くことと、ユニットテストを自動化することについて、Bolboaca氏にインタビューした。ユニットテストは、技術的なものであり、コーディングの詳細や、プログラム言語の特定のコンセプトにさえ注目することがあります。ユニットテストは、Javaのような静的プログラミング言語や、Rubyのような動的プログラミング言語とは異なって見えます。そのため、ユニットテストに対して、主に責任があるのは、プログラマであるべきです。テスタは、テスト計画の作成方法や、同値分割や境界値分析のような特定の分析によって、テストの興味深い値を割り出す方法をよりよく知っています。そのため、プログラマは、テスタからこのような知識を"盗む"必要があります。ペアになって、一緒にテストを書くこともできますが、実装するのはプログラマです。私の経験では、ペアになるのが最良の選択肢です。テストとプログラマはお互いよりよく学び、視野を広げられます。チームは、製品コードが書かれた後で、ユニットテストを書くことができます。これをテストアフターと呼びます。テストアフターでは、テストできるように書くことを考慮して、製品コードを書かなければならないため、難しいことがあります。このアプローチを選んだ場合、私たちは、製品コードをコードレビューのプロセスに通して、確実にテストできるようにする必要があります。した場合のみ、私たちはプログラマとテスタのペアでテストを作成し続けられます。テストファーストアプローチもあり、仲間から多くのテストの知識を盗むプログラマにはこちらを薦めます。このアプローチを使う場合、私たちは、まず問題を分析し、1つのユニットテストを書きます。それから、そのテストのために最も簡単な実装コードを書き、それから、1つのユニットテスト、その実装、というように続きます。チームがこのレベルに達すると、ユニットテストを書いているプログラマは、半分テスタだと言えるでしょう。テストファーストは、多くのテストの知識を必要としますから。この場合、テスタは、最後にユニットテストをレビューし、受け入れテストを書くことに集中します。Zilberfeld氏は、インタビューのテストファーストアプローチで、テストファーストアプローチがもたらす利益について語っている。テストファーストは、何が動くべきかを定義します。テスト形式で定義があるので、特定の問題を解決するために、どのようなコードを書く必要があるのかを定義します。テストを実行するだけで、動く機能があるかどうかを簡単に知ることができます。このようにすれば、ずっと多くのカバレッジを得られます。テストを最後まで残しておくよりも、非常に優れた開発作業になります。これらのテストを書いて、シナリオを特定している時に、いろいろな疑問が出てくるので、問題のある場所をより多く見つけられます。テストアフターでは、そのような議論は全く起きないこともあります。開発者は、解決に必要なことよりも、自分が考えたことをコードにします。Lopian氏は、QA部門が消えた日という記事で、ユニットテストがQAを潰す可能生があることを説明した。ユニットテストは、特定のコードが適切に動作し、ソフトウェアのパズルに、正確に取り込まれていることを確認するためのテスト手法です。ユニットテストでコードの90%を適切にチェックできることが示されています。QAの手動テストツールとは違い、正確にビルドし、自動的にテストするユニットテストは、コードをリアルタイムでテストしながら、コードベースを進化させられます。ユニットテストは、テスト計画に従い、分析するプロセスであり、テスト計画は自動化できます。これらのテストを自動化するために、いくつか覚えておくと役に立つことがあります。テストの名前にドメイン言語を使う私たちはテストを書いて、それでおしまいにすることがよくあります。コードは、書かれるよりも、読まれることの方が多いのです。同僚や、未来の自分に優しくするために、テストの名前を明確にしましょう。技術的な名前ではなく、ドメインから名前を使いましょう。ようなテストの名前は、明確ではありません。"InvalidCustomerIsRejectedByOrder"のような、分かりやすい名前を書くべきです。このようにすれば、ビジネスドメインを知っているすべての人たちが、そこで何をテストしているのか分かるでしょう。あなたの顧客でさえも。テストを短くするユニットテストは、1つの目的を持つ、短くて明確なものです。最良のテストは、3、4行のコードで、そのコードを読む人は誰でも、すぐに分かるようになっています。私たちは、このような数多くの小さいユニットテストが必要です。これらのテストは、製品免疫システムのように、各テストが免疫細胞のように一緒に動きます。不具合が現れれば、1つの小さなテストが、どこに問題があるのか正確に教えてくれるはずです。このようにすれば、素早いフィードバックと、簡単な開発とテストサイクルを持てます。1つのテストに1つのアサート1つのテストに2つ以上のアサートがある場合、2つ以上のことをテストしていることになります。この場合、テストの名前は奇妙で不明確になります。テストは長すぎて、フィードバックははっきりしません。どのアサートが成功して、どのアサートが失敗したのか、決して知ることはできません。順番に3つのアサートがあるとしましょう。最初のアサートが失敗すると、残りの2つは確認されません。製品コードを変更した時、残りの2つのアサートは動作を保証してくれません。この場合、セイフティネットと回帰テストの幻を見たにすぎません。つながっていないテストテストをつなげる習慣をよく見かけます。それは、大抵、計画した部分を設定するのが、とても難しいからです。これは解決策ではありません。つながりの中で、他のテストに依存したテストは、そのつながりのトップにあるテストのために、よく失敗します。この場合、テストが通るようにコードを変えるかもしれませんが、テストが未対応のために、検証されていない欠陥を持ち込むかもしれません。免疫システムの免疫細胞のように、テストは、いつもお互いに独立していなければなりません。テストは、製品には依存しますが、お互いには依存しません。適切なツールを使うテストフレームワーク、モックフレームワーク、テストランナ、性能テストツール、セキュリティテストツール等、様々なツールがあります。仕事に対して、適切なツールを使うようにしましょう。自分が知っているというだけで、そのツールを使わないようにしましょう。xUnitフレームワークは、大抵、どのタイプの自動化にでも合いますが、性能とセキュリティは専門的なフレームワークを使います。実行可能な仕様になるように、よいテストを書けば、xUnitも使えますが、自分の人生を簡単にするために、BDDフレームワークを使いたいかもしれません。テストフレームワークを選ぶことは、中長期的に決められるべき決定であることを、覚えておいてください。学習の費用だけでなく、使い方の費用や維持費についても考えましょう。現在の市場では、ますます速く機能を提供する必要があるので、製品の検証プロセスを賢く検証して、自動化する必要があります。これが、今日では、自動化が重要である理由です。ユニットテストは、産業製品から来ていますが、大抵の人たちはそのことを忘れています。産業では、私たちは小さな部品をそれぞれテストする必要があります。その部品が基準通りの品質であれば、部品を組み立てるために、次の段階でその部品を使えます。ソフトウェアでは、私たちは、ユニットが何かという明確な定義は持っていません。メソッド、クラス、モジュール等の様々な意見があります。最初に難しいのは、何がユニットかをすべてのチームメンバで一緒に決めることです。それに応じて、テストを書きます。私にとって、ユニットはとても小さく、エンジンの中のネジか、家具の釘の大きさです。私の秘訣は、ユニットが何かを定義して、テストレビューフェーズの間、その決まりを守ることに集中することです。ユニットテストは、プログラミングとテストが混じり合ったものです。プログラマは、シンプルで速い、メンテナンスしやすいテストを書くために、数多くのテストコンセプトを知る必要があります。テストカバレッジ、ポジティブテスト、ネガティブテストのような、いくつかの必要不可欠なコンセプトについて、同僚のテスタから学ぶことです。ユニットテストに関して、もう1つ、よく忘れるのは分析についてです。私たちは、考えずに、直ちにテストを書き始めることはありません。問題を分析し、可能ならば、分割し、それから、書かなければならないユニットテストは何かを考えます。ここでアドバイスしたいのは、常にシステムのアウトプットから始めることです。そのアウトプットを生成する、起こりうるインプットを明らかにします。Matts氏に感謝します。ユニットテストを書いている時に、その問題のドメインから言葉を使うべきです。テストは、その機能が製品に存在する理由を表すべきです。ビジネスドメインを知っていて、プログラミングを知らない人が、テストを読めるようにすべきです。アナリストとペアになることは、その方向で、とても役に立ちます。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員��して、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。