キュウリと1Scriptとともに1Cでの開発にBDDを適合させます

ソリューションのテストの費用は誰が負担しますか？ 特に、顧客（内部または外部）が会計システムの開始を要求し、必要なシステムがどれほど悪いかを示していない場合はどうでしょうか？ この質問は、あらゆる開発、解決策で「聖戦」の十分に大きな波を引き起こします。 これらは1Cで書かれているか、1Cで書かれていない-これは永遠の「戦い」です。誰もテストするのが好きではなく、誰もが新しい興味深いタスクを「コーディングする」のが好きです。



しかし、少なくとも地面から降りようとするためには、概念としてのテストが開発プロセスを指すことを理解する必要があります。 そのため、開発者をテストする必要があります。 しかし、できるだけ便利にするにはどうすればいいですか？

BDD、DDD、TDD、PDD、SDD、およびその他のDD

テストの問題、またはソリューションの品質の問題を考えると、賢くてあまり人々はほとんど槍を打ちません。







「テストする必要がありますが、テストするのではなく開発する必要があります。」



また、これに別の矛盾が追加されます



「将来のユーザーのすべての可能なアクションを予測する必要がありますが、将来のユーザーのすべてのアクションを予測することはできません」







設計と開発に膨大な数のアプローチを追加すると、すべてが悪化します。 たとえば、問題の本質を説明する必要がある場合、どのように分類すればよいですか。



ドメインDD-顧客の目標が将来のシステムの基本的なエンティティとして定式化される場合の開発方法： 「商品、在庫、償却および転記の行為が必要」



レポートDD-データ分析を含む最終レポートの形式で顧客の目標を策定するときの開発方法： 「損益計算書が必要です」



ユーザーインターフェースDDは、顧客の目標が最終的なユーザーインターフェースとして定式化される場合の開発方法です 。 「パスを発行するために、パスの従業員用にこのフォームが必要です」



ビヘイビアDDは、顧客の目標がシステムで期待される最終プロセスまたは相互接続されたプロセスのグループとして定式化される場合の開発方法です。 「モスクワからの車の発送を記録する場合、注文ステータスを変更し、発送時間を修正し、間接費も考慮する必要があります注文の費用で輸送するために”



それとは別に、通常はどこにも説明されていない3つのアプローチを強調する価値があります。



サボタージュDDは、顧客の目標が生産システムでの直接的な開発を必要とする期限の短縮として定式化される場合の開発方法です。 「ブール=カモミール=小道具をフォームに緊急に追加します。 」 顧客が開発チームで制御されたカオスを構築しようとするときに使用されます-政治的な目的で使用されます。



Moratorium DDは、顧客の目標が機能の立ち上げではなく、企業によって承認された規制や基準に準拠する場合の開発方法です。 「システムの変更は<Accordance Sheet>と一貫している必要があります。設計、開発、プロトタイプ作成作業は、プロジェクトの指示と実行可能性調査 。 」



顧客の目標が機能のリリースのタイムラインを短縮することなくソリューションの品質を向上させることである場合、 Pain DDは過渡的な開発方法です： ちなみに、今年は給与計算基金が削減されました-専用のテスターは取得できません。」







分類は確かに不器用で非常に現実的なものですが、この主題に関するスマートブックを読むための専門家を準備するには十分です。



FeatureDD （顧客の目標が小さな軽量機能として定式化される場合の開発）、およびModelDD （顧客の目標がフィールドを持つ最終テーブルとして定式化される場合の開発）もありますが、私は通常以下の理由でそれらを使用しません：

• 1Cの世界では、多くの場合、顧客は期待される動作「行動」をすぐに定式化します。 「行動」は常に複雑であるため、シナリオを分解/分類するときに機能が自動的に発生します。
• 1Cの世界では、すべてのドメイン/モデルは常に複雑（またはむしろ複雑な機能）であり、3つ以上の依存エンティティと3つ以上の機能関係があります。 そして、正しいモデルは、複雑なドメインの分解の一部として、それ自体ですでに発生しています-そうでなければ、正しいドメイン依存関係グラフを作成できません。 v8.1c.ru/modelをよく見ることをお勧めします。システムは、DDDとMDDを組み合わせたものであり、ChangeManagementSystemを少し変更しただけです。

突然、これらの略語が何であるかを知らない人：



DD-駆動型開発 （「スルー」または「目標からの開発」）は、ソフトウェアエンジニアリングの開発プロセスを整理する方法の1つです。 en.wikipedia.org/wiki/Software_development_processに個別の方法論として含まれています。

eDSLのBDD開発者環境

eDSLの世界に精通している人、そして前の記事から理解したように、Habrには多くの人がいます。 理解していない人のために、私は言います：1Cの世界では、顧客は最終的なビジネスマンではなく、企業のすべてのユーザーであるという事実によります。事実、どのアプローチも適用します。 誰かが報告を望み、誰かが行動を起こし、誰かが一般的に奇妙です。 したがって、通常の1Cスペシャリストのコミュニティでは、 xDrivenDevelopmentという定式化を使用します。ここで、 xは、顧客の目標に応じた任意のアプローチです。 著者はコミュニティメンバーの1つに属し、最初はyDrivenDevelomentのように聞こえました 。ここで、 yは開発者が実行する特定の目的関数です。



しかし、テストに戻ります。 したがって、入力には次のデータがあります。

• テストする必要があります（そしてどこへ行くか）
• 開発が必要です（eDSLプラットフォームはこのためのものです）
• 開発プロセスへのアプローチは異なる場合があります（そして、それについて行うことは何もありません）。
• すべてのテストを書くことはできません（まあ、または書かれていますが、システムの寿命の10年後）
• システムの要件はかなり混oticとしているため、要件を設定する方法も異なります。

1Cプラットフォームでの振る舞いを通じて開発する能力を作成しようとしています。



仕事には、次のものが必要です。

• 1C users.v8.1c.ru/distribution => 8.3。*
• git-msgit msysgit.github.io => 1.7
• ルビーwww.ruby-lang.org/en/downloads => 2.0
• python wiki.python.org/moin/Python2orPython3 => 2.5

また、動作による1Cソリューションのテストへのアプローチを反映する概念：

• github.com/silverbulleters/vanessa-behavoir

追加のサブモジュールとして使用します

• github.com/xDrivenDevelopment/precommit1c

この場所にたどり着いた1Cの専門家の中には、「広く開かれた目」を作り、おそらく記事を閉じる人もいます。 残りについては、次の点に注意します。

msgitをインストールするとき、$ PATHだけでなく、すべてのユーティリティ（実際の1Cニックネームは* nix world-touch、mv、rm、grepなどのコンソールユーティリティに慣れる必要がある）でインストールされるようにしたいと思います。 .d。）

ルビー 「キュウリ」をインストールする必要があります

python -gitフックを使用していました（ソースファイルを取得するには、バイナリ1Cファイルをリポジトリに配置するインターセプトを使用します。結局、ソースコードリポジトリはソースコードリポジトリに存在する必要があります）。



理論から実務への急激な移行から現在苦しんでいる人々のために、私は条件に来て、読み続けることを提案します：



最初に理解しておくべきことは、テストもコードです。 また、コードについては、コードリポジトリを作成するだけです。 したがって：

$ mkdir EnterpriseAccounting $ cd EnterpriseAccounting $ git init./ $ mkdir features $ mkdir tests $ mkdir src $ touch README.md
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

残っているのは、gitサーバーのどこにテストを保存するかを把握することです

 $ git set origin https://dev.example.com/foobar/EnterpriseAccounting $ git push
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最終タスクのテスト、これは関数アルゴリズムのテストではありません

問題に直接進みます。 繰り返しますが、1C自動テストの開発を開始するときの主な問題は、ビジネスの最終的な機能を「テストする方法」が理解できないことです。 おそらく、有名なxUnitプロジェクトの名前は「邪悪なトリック」を果たしています。これは、多くの流行語を読むen.wikipedia.org/wiki/XUnitを指しますが、ビジネスタスクの最終テストからはかけ離れています。



そして、ここで、自動テストを担当する初心者開発者が「ステレオタイプを破る」ようになります。事実、1C Configuratorを使用すると、機能について考える必要はなく、「なぜ」「誰」が機能を必要とせずに、必要な期待される動作をすぐに実現できます。 当初、すべてのビジネス顧客とeDSL言語の専門家は、可能な限り「状況に応じて」いると考えられています。 1つの動作については、これが本当である可能性が最も高くなりますが、一連の予想される動作および複雑なシナリオの場合、脳はタスクのシナリオ全体をコンテキストに保持できません。 この直後に、予想される動作をコードとして扱い始めます。

開発者向けの通常のサンプルプロセス

（タスクアカウンティングシステム内の）顧客からのタスクは次のように聞こえます

「クライアントが私たちに出荷した金額以上を支払った場合、前払いとしてお金を考慮する必要があります。」

それでは、実際にどのように見えるかを見て、1CでBDDに必要なものを推定しましょう。

• Gherkin言語のパーサー。2つの機能を実行します。テストの手順を生成するのを支援するためです。実際、後で既製のテストを実行し、その通過に関するレポートを生成します。 これらの目的のために、我々はキュウリ （同じ「キュウリ」）を使用します
• Cucumberから既製のテスト名（パラメーターと一緒に）を受け取って、1C外部処理形式で既製の処理ファイルを作成するツールがあると便利です（自動化できるものはすべて自動化する必要があります）。 技術的には、これは1Scriptで記述されたスクリプトです。 ワイヤープロトコルキュウリ、1Scriptソケット、および1Cを使用したOLE接続を介して、Cucumberと1Cを相互に接続できます 。 つまり 入り口で機能ファイルを取得します-出力では、開発者に提供できる1C対応の処理を行います。 そして、これらすべてをワンクリックで。
• 私たちが受ける治療は私たちのテストです。 これはコードであり、コードは保存およびバージョン管理する必要があります。 このために、Gitを配置します。
• 開発者がこれらのテストをコードで埋めた後、それらをソースに分解する必要があります（そして、どのように、リポジトリにバイナリファイルのみを保存しないのか）。 この目的のために、 xDrivenDevelopmentコミュニティからPrecommit1cを取得します。 これで、完成したファイルをGitに配置すると、解析、分解、逆コンパイル、未分類になります（必要なファイルを選択します）。 そして、それ自体で、ワンクリックで自動的に理解できます。

次のステップは、「行動による開発」のかなり重要で非常に義務的なステップです。行動の予想シナリオ（または私たちの分析、または有能な顧客）を作成します。 実際、ガーキン、そしてそれを使用しますが、将来のテストシナリオのグループを記述するDSL言語があるという事実によって、ここで私たちを救います。 あなたはおそらく、私が将来のテストについて何を言ったか疑問に思ったでしょうか？ ただし、調整する必要があります-BusinessReadableDSLを使用してシナリオを説明した後、実際にテストする必要があるものと実装する必要があるものを理解します（このトピックに関するMartin Fowlerの記事を参照してください）。



そのため、問題の元のステートメント、次の内容に基づいて記述するフィーチャーファイルがあります。

 $ touch ./feature/account_loan.feature $ notepad++ ./feature/account_loan.feature
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 :                          ,           ,    :    ' 3.0 ()'    ' '    '   1'    02.01.2014    '   2'    03.01.2014     :          ' '  2   2 ' '   1000  300      ' '   1100       '62.01'  '   1'   1000      '62.01'  '   2'   100    '62.01'  '   2'     200 
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「GenerateEpf」パラメーターを指定してvanessa-behavior.osを実行し、テスト用の完成した処理ファイルを取得します。

 $ oscript.exe vanessa-behavior.os --GenerateEpf --ProjectPath="<   Feature >" --1cConnectString="File=<1>"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、それがすべてであったものを取得します-動作に基づいて処理をテストし、 その後、組み込みの1C言語のコードを入力します







ご覧のとおり、次のことが起こりました。



機能ファイルの各行に手順が作成されました。

たとえば、文字列

    ' 3.0 ()'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

になった

  (01) 
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらのプロシージャーを呼び出すためのパラメーター（番号、行、日付）が定義され、いわゆるスニペットも定義されました。次に例を示します。

 //“@(01,02)”
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで何ができるか見てみましょう。

最初に目を引くのは、パラメーター名Param01Strokaがあまり明確ではないことです。 まあ、それを取り、名前を変更してください、例えば、 Configuration Nameで 。 はい、プロシージャの名前はThere is a Configurationに置き換えられます 。

それは判明します：

  () 
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、同じ機能ファイルを使用して1C処理を再度生成しようとすると、プログラムは古い名前のプロシージャを見つけることができず、すべてが機能しなくなることがあります。 しかし、ここでスニペットが私たちの助けになります

  //@(01)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

どのメソッドを呼び出すかを常に決定できます（ただし、処理ソースを解析し、スニペットとプロシージャの実際の名前のテーブルを作成する必要がありますが、そのような些細なことは私たちを怖がらせません）。



あなたが気づくことができる2番目のものは、機能ファイルに2つの同様の行があったことです：

    '   1'    02.01.2014    '   2'    03.01.2014
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、これらのメソッドは1つだけ作成されました。

  (01,02) 
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スニペットは両方の行で同じになるため、これは驚くことではありません。 したがって、ここでコードの再利用が行われているように見えるかもしれません。 Iiiiiiiii ...はい！ これだ！ この機能ファイル（または他のプロジェクト）のどこかに次のように記述します。

     '-  '    '- '
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このテストコードは、 ExistingAccount withAccount Dateメソッドに既に実装されていることがわかります。



さらに、このメソッドは私たちの前に他の誰かによって実装されたことが判明するかもしれません。 そして、それを再利用するだけです。 そして、これは自然に起こります。 これはプログラマーの夢ではありませんか！ 顧客は自分が望むものを書きます（これが私たちの機能ファイルです）-そして、コードの半分は既に実装され、テストされています（つまり、テストでカバーされています）。その場でピックアップされます！

友人、BDDへようこそ！







ミニサマリーを要約します。

• 顧客が望むものがあります。それはガーキンの宣言言語で記述されています。
• ジェネレーターを起動します-コードを入力する必要がある既製のテストファイルを取得します。
• テストを記述します（または、新しい機能を通じてユーザーアクションの記録を生成します）と同時に、顧客が受け取りたい機能を記述/構成します。
• vanessa-behavior.osを起動します。テストは、お客様のすべての同じ機能を使用して実行されています。
• jsonまたはhtmlなどのテストに合格したことに関するレポートを取得します（ Allureプロジェクトを忘れないでください ）

ある記事では、BDDのような大きなトピックと、それを1Cの世界に適応させる方法をカバーするのは困難です。 このトピックに完全に焦点を当てた別の記事があることを願っていますが、すでにより詳細な例があります。

機能インベントリと技術的負債

通常、最初の記事で述べたように、この資料を研究する人々は、テストを通して書き始めることを拒否します。



これは、次の2つの理由で発生します。

• 「どのようにテストするかを理解して初めて作業に作業を取り入れる」というルールの導入後、主要な時間費用は、請負業者、命名法、会計方針などのプライマリおよびマスターデータのテストの構築に費やされ始めます。 同時に、テストデータを生成する必要があります。これは、自動化されたテストの基礎がクリーンであるべきだということが全員に明らかになるためです。 誰もがこれを行う準備ができているわけではありません。X（BDDへの移行）までの「私たちが満たした」すべてを遡及的に見なければならないからです。 この問題は、いわゆる「技術スプリント」方法-顧客と調整する方法（または調整しない方法）-これはアジャイルとは別の歌です。
• 難しい...結局のところ、BDD | xDDはエンジニアリングプラクティスに由来するため、チームの開発者の高いレベルの責任が必要です。 その6年が無責任である前に責任を負うことは常に困難です。 この問題は、2つの方法で解決されます-いわゆる社会的圧力の方法論とリリース管理プラクティスの導入。 つまり、「テストなしでfu fu fuを記述する」場合、および実動用のテストなしのリリースが、作業システムを担当するエンジニアによって許可されていない場合です。 あなたが「多腕のシヴァ」であるなら、内部のIT完璧主義だけがあなたを救うでしょう。
• 一般に、「予想される動作による開発」に切り替えると、チームのコストが一時的に増加します。 現在、次の数字があります。通常の1Cプログラマーのレベルの5人のチームで、開発速度の向上とエラー数の減少（品質改善）が1か月以内に開始されます。 したがって、1か月以内にチーム全体が永続的なストレスに耐え、;-)に耐えなければなりません。 マネージャーにとっても、機能ファイルの形式で要件収集フェーズを個別に起動して、テストフェーズを開始するだけで、古い方法の開発を中断できないことに注意する必要があります（これは概念自体と矛盾しますが、これは移行期間には受け入れられます）。

---

よくある質問



Q：試しましたが、成功しませんでした。 どうやって使うの？

A：プロジェクトは1Scriptの最新（開発）バージョンで動作しており、 1.0.9リリースのリリースを待っています。また、現在のタスクに合わせて体系的に更新されます。 したがって、心配しないでください-すべてがなります。



Q：この主題について何を読むべきですか？

A：多くの資料がありますが、：

• 次回のAgileDays2015の基調講演者がキュウリの作者になるという事実に注目します。
• 1年前にリリースされたJohn Ferguson SmartによるBDD In Action
• Dan Northの記事を読むことも強くお勧めします

Q：ガーキンがここにいるのはなぜですか

A：要件を記述するための Gherkin DSL言語は、要件の管理の問題と、それが自動的に解決される方法への直接の参照です。



Q：標準1Cソリューションの典型的な機能をテストする理由は何ですか？

A：繰り返し述べたように、自動テストは「長期にわたる」ものです。 実装されたシステムから予想される動作が存在することで、標準の1C構成の新しいバージョンへのアップグレードが簡素化され、標準構成に基づいて開発が行われます。 確かに、この問題はすでに別の「オペラ」からのものです（英語を知っている人向け） 。 これに加えて、既に拡張の可能性があるサイドラインを覗くことを強くお勧めします。拡張は既にテストを考慮して開発する必要があります。



Q：xUnitFor1Cについての出版物はいつですか？

A：長い議論の後、xDrivenDevelopment組織の著者グループがxUnitでの発行を行うべきだと考えました。 最初の8時間のビデオコースとInfostartでの発行しか共有できませんが、 この製品のリーダーは xUnitFor1Cでの発行を行う必要があります



Q：次の出版物は何ですか？

A： docker-composeおよびdocker-machineの公式リリース後、および1.5へのdockerの開発後も1CのDockerのままであり、今では尊敬されているHabrコミュニティに本当に役立ちます。