এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

টেস্ট ম্যাপিং

এটি পরীক্ষার ম্যাপিংয়ের একটি সংক্ষিপ্ত ভূমিকা এবং অ্যান্ড্রয়েড ওপেন সোর্স প্রজেক্টে (AOSP) পরীক্ষা কনফিগার করা শুরু করার একটি ব্যাখ্যা।

পরীক্ষা ম্যাপিং সম্পর্কে

টেস্ট ম্যাপিং হল একটি গেরিট-ভিত্তিক পদ্ধতি যা ডেভেলপারদের সরাসরি অ্যান্ড্রয়েড সোর্স ট্রিতে প্রি-সাবমিট এবং পোস্ট-সাবমিট পরীক্ষার নিয়ম তৈরি করতে দেয় এবং শাখা এবং ডিভাইসগুলির সিদ্ধান্তগুলি পরীক্ষার পরিকাঠামোতে পরীক্ষা করার জন্য ছেড়ে দেয়। টেস্ট ম্যাপিং সংজ্ঞা হল TEST_MAPPING নামের JSON ফাইল যা আপনি যেকোনো উৎস ডিরেক্টরিতে রাখতে পারেন।

Atest সংশ্লিষ্ট ডিরেক্টরিতে প্রি-সাবমিট পরীক্ষা চালানোর জন্য TEST_MAPPING ফাইল ব্যবহার করতে পারে। টেস্ট ম্যাপিংয়ের মাধ্যমে, আপনি Android সোর্স ট্রির ভিতরে একটি ন্যূনতম পরিবর্তনের সাথে চেক জমা দেওয়ার জন্য পরীক্ষার একই সেট যোগ করতে পারেন।

এই উদাহরণগুলি দেখুন:

টেস্ট ম্যাপিং টেস্ট এক্সিকিউশন এবং রেজাল্ট রিপোর্টিং এর জন্য ট্রেড ফেডারেশন (TF) টেস্ট জোতার উপর নির্ভর করে।

পরীক্ষার গ্রুপ সংজ্ঞায়িত করুন

টেস্ট ম্যাপিং গ্রুপ পরীক্ষা করে একটি টেস্ট গ্রুপের সাথে। একটি পরীক্ষার গ্রুপের নাম যেকোনো স্ট্রিং হতে পারে। উদাহরণস্বরূপ, পরিবর্তনগুলি যাচাই করার সময় প্রি-সাবমিট চালানোর জন্য পরীক্ষার একটি গ্রুপের নাম হতে পারে। এবং পোস্ট সাবমিট পরিবর্তনগুলি একত্রিত হওয়ার পরে বিল্ডগুলিকে যাচাই করতে ব্যবহৃত পরীক্ষা হতে পারে।

প্যাকেজ বিল্ড স্ক্রিপ্ট নিয়ম

একটি প্রদত্ত বিল্ডের জন্য ট্রেড ফেডারেশন টেস্ট হার্নেস পরীক্ষা মডিউল চালানোর জন্য, এই মডিউলগুলিতে অবশ্যই Soong- এর জন্য একটি test_suites সেট থাকতে হবে বা এই দুটি স্যুটের একটিতে মেক করার জন্য একটি LOCAL_COMPATIBILITY_SUITE সেট থাকতে হবে:

general-tests এমন পরীক্ষার জন্য যা ডিভাইস-নির্দিষ্ট ক্ষমতার উপর নির্ভর করে না (যেমন বিক্রেতা-নির্দিষ্ট হার্ডওয়্যার যা বেশিরভাগ ডিভাইসে নেই)। বেশিরভাগ পরীক্ষা general-tests স্যুটে হওয়া উচিত, এমনকি যদি সেগুলি একটি ABI বা বিটনেস বা HWASan-এর মতো হার্ডওয়্যার বৈশিষ্ট্যগুলির জন্য নির্দিষ্ট হয় (প্রতিটি ABI-এর জন্য একটি পৃথক test_suites টার্গেট আছে), এবং এমনকি যদি সেগুলিকে একটি ডিভাইসে চালাতে হয়।
device-tests এমন পরীক্ষার জন্য যা ডিভাইস-নির্দিষ্ট ক্ষমতার উপর নির্ভর করে। সাধারণত এই পরীক্ষাগুলি vendor/ অধীনে পাওয়া যায়। ডিভাইস-নির্দিষ্ট শুধুমাত্র সেই ক্ষমতাগুলিকে বোঝায় যা একটি ডিভাইসের জন্য অনন্য, তাই এটি JUnit পরীক্ষার পাশাপাশি GTest পরীক্ষার ক্ষেত্রে প্রযোজ্য (যা সাধারণত ABI নির্দিষ্ট হলেও general-tests হিসাবে চিহ্নিত করা উচিত)।

উদাহরণ:

Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests

একটি পরীক্ষা স্যুটে চালানোর জন্য পরীক্ষাগুলি কনফিগার করুন

একটি পরীক্ষা স্যুটের ভিতরে চালানোর জন্য, পরীক্ষা:

কোন বিল্ড প্রদানকারী থাকতে হবে না.
এটি শেষ হওয়ার পরে অবশ্যই পরিষ্কার করতে হবে, উদাহরণস্বরূপ, পরীক্ষার সময় উত্পন্ন কোনো অস্থায়ী ফাইল মুছে ফেলার মাধ্যমে।
ডিফল্ট বা মূল মান সিস্টেম সেটিংস পরিবর্তন করা আবশ্যক.
একটি ডিভাইস একটি নির্দিষ্ট অবস্থায় আছে অনুমান করা উচিত নয়, উদাহরণস্বরূপ, রুট প্রস্তুত। বেশিরভাগ পরীক্ষা চালানোর জন্য রুট সুবিধার প্রয়োজন হয় না। যদি কোনো পরীক্ষার জন্য অবশ্যই রুটের প্রয়োজন হয়, তাহলে এটির AndroidTest.xml এ RootTargetPreparer সাথে নিম্নলিখিত উদাহরণের মতো উল্লেখ করা উচিত:
```
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
```

টেস্ট ম্যাপিং ফাইল তৈরি করুন

পরীক্ষার কভারেজ প্রয়োজন এমন ডিরেক্টরির জন্য, উদাহরণের অনুরূপ একটি TEST_MAPPING JSON ফাইল যোগ করুন। এই নিয়মগুলি নিশ্চিত করে যে পরীক্ষাগুলি প্রি-সাবমিট চেকগুলিতে চালানো হয় যখন কোনও ফাইল সেই ডিরেক্টরিতে বা এর যে কোনও সাবডিরেক্টরিতে স্পর্শ করা হয়।

একটি উদাহরণ অনুসরণ করুন

এখানে একটি নমুনা TEST_MAPPING ফাইল রয়েছে (এটি JSON ফর্ম্যাটে কিন্তু মন্তব্য সমর্থিত):

{
  "presubmit": [
    // JUnit test with options and file patterns.
    {
      "name": "CtsWindowManagerDeviceTestCases",
      "options": [
        {
          "include-annotation": "android.platform.test.annotations.RequiresDevice"
        }
      ],
      "file_patterns": ["(/|^)Window[^/]*\\.java", "(/|^)Activity[^/]*\\.java"]
    },
    // Device-side GTest with options.
    {
      "name" : "hello_world_test",
      "options": [
        {
          "native-test-flag": "\"servicename1 servicename2\""
        },
        {
          "native-test-timeout": "6000"
        }
      ]
    }
    // Host-side GTest.
    {
      "name" : "net_test_avrcp",
      "host" : true
    }
  ],
  "postsubmit": [
    {
      "name": "CtsDeqpTestCases",
      "options": [
        {
          // Use regex in include-filter which is supported in AndroidJUnitTest
          "include-filter": "dEQP-EGL.functional.color_clears.*"
        }
      ]
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

গুণাবলী সেট করুন

উদাহরণে , presubmit এবং postsubmit প্রতিটি পরীক্ষার গ্রুপের নাম। পরীক্ষা গোষ্ঠী সম্পর্কে আরও তথ্যের জন্য পরীক্ষা গোষ্ঠী সংজ্ঞায়িত করুন দেখুন।

আপনি পরীক্ষার মডিউলের নাম বা ট্রেড ফেডারেশন ইন্টিগ্রেশন পরীক্ষার নাম (পরীক্ষা XML ফাইলের রিসোর্স পাথ, উদাহরণস্বরূপ, uiautomator/uiautomator-demo ) name বৈশিষ্ট্যের মান সেট করতে পারেন। মনে রাখবেন যে name ক্ষেত্রটি ক্লাসের name বা পরীক্ষা পদ্ধতির name ব্যবহার করতে পারে না। চালানোর জন্য পরীক্ষাগুলিকে সংকুচিত করতে, include-filter মতো বিকল্পগুলি ব্যবহার করুন। include-filter নমুনা ব্যবহার দেখুন।

একটি পরীক্ষার host সেটিং নির্দেশ করে যে পরীক্ষাটি হোস্টে চলমান ডিভাইসবিহীন পরীক্ষা কিনা। ডিফল্ট মান false , যার অর্থ পরীক্ষা চালানোর জন্য একটি ডিভাইস প্রয়োজন৷ সমর্থিত পরীক্ষার ধরনগুলি হল GTest বাইনারিগুলির জন্য HostGTest এবং JUnit পরীক্ষার জন্য HostTest ৷

file_patterns অ্যাট্রিবিউট আপনাকে যেকোন সোর্স কোড ফাইলের আপেক্ষিক পাথের সাথে মিলের জন্য নিয়মিত এক্সপ্রেশন স্ট্রিংগুলির একটি তালিকা সেট করতে দেয় ( TEST_MAPPING ফাইল ধারণকারী ডিরেক্টরির সাথে সম্পর্কিত)। উদাহরণে , CtsWindowManagerDeviceTestCases পরীক্ষা শুধুমাত্র তখনই প্রিসবমিটে চলে যখন একটি জাভা ফাইল Window বা Activity দিয়ে শুরু হয়, যেটি TEST_MAPPING ফাইল বা এর যেকোনো সাবডিরেক্টরির মতো একই ডিরেক্টরিতে বিদ্যমান থাকে। ব্যাকস্ল্যাশগুলি (\) একটি JSON ফাইলে থাকায় এস্কেপ করা দরকার৷

imports বৈশিষ্ট্য আপনাকে সামগ্রী অনুলিপি না করে অন্যান্য TEST_MAPPING ফাইলগুলিতে পরীক্ষা অন্তর্ভুক্ত করতে দেয়৷ আমদানি করা পথের মূল ডিরেক্টরিতে TEST_MAPPING ফাইলগুলিও অন্তর্ভুক্ত করা হয়েছে৷ টেস্ট ম্যাপিং নেস্টেড আমদানির অনুমতি দেয়; এর অর্থ হল দুটি TEST_MAPPING ফাইল একে অপরকে আমদানি করতে পারে এবং টেস্ট ম্যাপিং অন্তর্ভুক্ত পরীক্ষাগুলিকে একত্রিত করতে পারে।

options অ্যাট্রিবিউটে অতিরিক্ত ট্রেডফেড কমান্ড লাইন বিকল্প রয়েছে।

একটি প্রদত্ত পরীক্ষার জন্য উপলব্ধ বিকল্পগুলির একটি সম্পূর্ণ তালিকা পেতে, চালান:

tradefed.sh run commandAndExit [test_module] --help

বিকল্পগুলি কীভাবে কাজ করে সে সম্পর্কে আরও বিশদে জানতে Tradefed-এ বিকল্প হ্যান্ডলিং পড়ুন।

Atest দিয়ে পরীক্ষা চালান

স্থানীয়ভাবে প্রি-সাবমিট পরীক্ষার নিয়মগুলি সম্পাদন করতে:

TEST_MAPPING ফাইল ধারণকারী ডিরেক্টরিতে যান।
কমান্ড চালান:
```
atest
```

বর্তমান ডিরেক্টরির TEST_MAPPING ফাইলে কনফিগার করা সমস্ত প্রি-সাবমিট পরীক্ষা এবং এর মূল ডিরেক্টরি চালানো হয়। অ্যাটেস্ট সনাক্ত করে এবং প্রি-সাবমিটের জন্য দুটি পরীক্ষা চালায় (এ এবং বি)।

বর্তমান ওয়ার্কিং ডাইরেক্টরি (CWD) এবং প্যারেন্ট ডিরেক্টরিতে TEST_MAPPING ফাইলগুলিতে প্রি-সাবমিট পরীক্ষা চালানোর এটি সবচেয়ে সহজ উপায়। Atest CWD এবং এর সমস্ত মূল ডিরেক্টরিতে TEST_MAPPING ফাইল সনাক্ত করে এবং ব্যবহার করে।

স্ট্রাকচার সোর্স কোড

এই উদাহরণটি দেখায় কিভাবে আপনি উৎস ট্রি জুড়ে TEST_MAPPING ফাইলগুলি কনফিগার করতে পারেন:

src
├── project_1
│   └── TEST_MAPPING
├── project_2
│   └── TEST_MAPPING
└── TEST_MAPPING

src/TEST_MAPPING এর বিষয়বস্তু:

{
  "presubmit": [
    {
      "name": "A"
    }
  ]
}

src/project_1/TEST_MAPPING এর বিষয়বস্তু :

{
  "presubmit": [
    {
      "name": "B"
    }
  ],
  "postsubmit": [
    {
      "name": "C"
    }
  ],
  "other_group": [
    {
      "name": "X"
    }
  ]}

src/project_2/TEST_MAPPING এর বিষয়বস্তু :

{
  "presubmit": [
    {
      "name": "D"
    }
  ],
  "import": [
    {
      "path": "src/project_1"
    }
  ]}

টার্গেট ডিরেক্টরি নির্দিষ্ট করুন

আপনি সেই ডিরেক্টরিতে TEST_MAPPING ফাইলগুলিতে পরীক্ষা চালানোর জন্য একটি লক্ষ্য ডিরেক্টরি নির্দিষ্ট করতে পারেন। নিম্নলিখিত কমান্ড দুটি পরীক্ষা চালায় (A, B):

atest --test-mapping src/project_1

পোস্ট সাবমিট পরীক্ষার নিয়ম চালান

আপনি src_path (CWD-তে ডিফল্ট) এবং এর মূল ডিরেক্টরিতে TEST_MAPPING এ সংজ্ঞায়িত পোস্ট-সাবমিট পরীক্ষার নিয়মগুলি চালানোর জন্যও এই কমান্ডটি ব্যবহার করতে পারেন:

atest [--test-mapping] [src_path]:postsubmit

শুধুমাত্র এমন পরীক্ষা চালান যাতে কোনো ডিভাইসের প্রয়োজন হয় না

আপনি --host এর জন্য Atest বিকল্পটি ব্যবহার করতে পারেন শুধুমাত্র সেইসব পরীক্ষা চালানোর জন্য যা হোস্টের বিরুদ্ধে কনফিগার করা হয়েছে যার জন্য কোনো ডিভাইসের প্রয়োজন নেই। এই বিকল্প ব্যতীত, Atest উভয় পরীক্ষা চালায়, যেগুলির জন্য একটি ডিভাইসের প্রয়োজন এবং যেগুলি একটি হোস্টে চলছে যার জন্য কোনো ডিভাইসের প্রয়োজন নেই৷ পরীক্ষা দুটি পৃথক স্যুটে চালানো হয়:

atest [--test-mapping] --host

পরীক্ষা গ্রুপ সনাক্ত করুন

আপনি Atest কমান্ডে পরীক্ষার গ্রুপগুলি নির্দিষ্ট করতে পারেন। নিম্নলিখিত কমান্ডটি src/project_1 ডিরেক্টরিতে ফাইলগুলির সাথে সম্পর্কিত সমস্ত postsubmit পরীক্ষা চালায়, যার মধ্যে শুধুমাত্র একটি পরীক্ষা (C) রয়েছে।

অথবা আপনি গ্রুপ নির্বিশেষে সমস্ত পরীক্ষা চালানোর জন্য :all ব্যবহার করতে পারেন। নিম্নলিখিত কমান্ডটি চারটি পরীক্ষা চালায় (A, B, C, X):

atest --test-mapping src/project_1:all

সাবডিরেক্টরি অন্তর্ভুক্ত করুন

ডিফল্টরূপে, Atest-এর সাথে TEST_MAPPING এ চলমান পরীক্ষাগুলি শুধুমাত্র CWD (বা প্রদত্ত ডিরেক্টরি) এবং এর মূল ডিরেক্টরিতে TEST_MAPPING ফাইলে কনফিগার করা প্রি-সাবমিট পরীক্ষা চালায়। আপনি যদি সাবডিরেক্টরিতে সমস্ত TEST_MAPPING ফাইলে পরীক্ষা চালাতে চান, তাহলে --include-subdir বিকল্পটি ব্যবহার করুন যাতে Atest-কে সেই পরীক্ষাগুলি অন্তর্ভুক্ত করতে বাধ্য করা যায়।

atest --include-subdir

--include-subdir বিকল্প ছাড়া, Atest শুধুমাত্র A পরীক্ষা চালায়। --include-subdir বিকল্পের সাথে, Atest দুটি পরীক্ষা চালায় (A, B)।

লাইন-স্তরের মন্তব্য সমর্থিত

আপনি একটি লাইন-স্তরের // বিন্যাস মন্তব্য যোগ করতে পারেন TEST_MAPPING ফাইলটি অনুসরণ করে সেটির বর্ণনা সহ। ATest এবং ট্রেড ফেডারেশন কোনো মন্তব্য ছাড়াই একটি বৈধ JSON ফর্ম্যাটে TEST_MAPPING প্রিপ্রসেস করে। JSON ফাইলটি পরিষ্কার রাখতে, শুধুমাত্র লাইন-লেভেল // ফরম্যাট মন্তব্য সমর্থিত।

উদাহরণ:

{
  // For presubmit test group.
  "presubmit": [
    {
      // Run test on module A.
      "name": "A"
    }
  ]
}

পরীক্ষা ম্যাপিং সম্পর্কে

এই উদাহরণগুলি দেখুন:

পরীক্ষার গ্রুপ সংজ্ঞায়িত করুন

প্যাকেজ বিল্ড স্ক্রিপ্ট নিয়ম

general-tests এমন পরীক্ষার জন্য যা ডিভাইস-নির্দিষ্ট ক্ষমতার উপর নির্ভর করে না (যেমন বিক্রেতা-নির্দিষ্ট হার্ডওয়্যার যা বেশিরভাগ ডিভাইসে নেই)। বেশিরভাগ পরীক্ষা general-tests স্যুটে হওয়া উচিত, এমনকি যদি সেগুলি একটি ABI বা বিটনেস বা HWASan-এর মতো হার্ডওয়্যার বৈশিষ্ট্যগুলির জন্য নির্দিষ্ট হয় (প্রতিটি ABI-এর জন্য একটি পৃথক test_suites টার্গেট আছে), এবং এমনকি যদি সেগুলিকে একটি ডিভাইসে চালাতে হয়।
device-tests এমন পরীক্ষার জন্য যা ডিভাইস-নির্দিষ্ট ক্ষমতার উপর নির্ভর করে। সাধারণত এই পরীক্ষাগুলি vendor/ অধীনে পাওয়া যায়। ডিভাইস-নির্দিষ্ট শুধুমাত্র সেই ক্ষমতাগুলিকে বোঝায় যা একটি ডিভাইসের জন্য অনন্য, তাই এটি JUnit পরীক্ষার পাশাপাশি GTest পরীক্ষার ক্ষেত্রে প্রযোজ্য (যা সাধারণত ABI নির্দিষ্ট হলেও general-tests হিসাবে চিহ্নিত করা উচিত)।

উদাহরণ:

Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests

একটি পরীক্ষা স্যুটে চালানোর জন্য পরীক্ষাগুলি কনফিগার করুন

একটি পরীক্ষা স্যুটের ভিতরে চালানোর জন্য, পরীক্ষা:

কোন বিল্ড প্রদানকারী থাকতে হবে না.
এটি শেষ হওয়ার পরে অবশ্যই পরিষ্কার করতে হবে, উদাহরণস্বরূপ, পরীক্ষার সময় উত্পন্ন কোনো অস্থায়ী ফাইল মুছে ফেলার মাধ্যমে।
ডিফল্ট বা মূল মান সিস্টেম সেটিংস পরিবর্তন করা আবশ্যক.
একটি ডিভাইস একটি নির্দিষ্ট অবস্থায় আছে অনুমান করা উচিত নয়, উদাহরণস্বরূপ, রুট প্রস্তুত। বেশিরভাগ পরীক্ষা চালানোর জন্য রুট সুবিধার প্রয়োজন হয় না। যদি কোনো পরীক্ষার জন্য অবশ্যই রুটের প্রয়োজন হয়, তাহলে এটির AndroidTest.xml এ RootTargetPreparer সাথে নিম্নলিখিত উদাহরণের মতো উল্লেখ করা উচিত:
```
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
```

টেস্ট ম্যাপিং ফাইল তৈরি করুন

একটি উদাহরণ অনুসরণ করুন

এখানে একটি নমুনা TEST_MAPPING ফাইল রয়েছে (এটি JSON ফর্ম্যাটে কিন্তু মন্তব্য সমর্থিত):

{
  "presubmit": [
    // JUnit test with options and file patterns.
    {
      "name": "CtsWindowManagerDeviceTestCases",
      "options": [
        {
          "include-annotation": "android.platform.test.annotations.RequiresDevice"
        }
      ],
      "file_patterns": ["(/|^)Window[^/]*\\.java", "(/|^)Activity[^/]*\\.java"]
    },
    // Device-side GTest with options.
    {
      "name" : "hello_world_test",
      "options": [
        {
          "native-test-flag": "\"servicename1 servicename2\""
        },
        {
          "native-test-timeout": "6000"
        }
      ]
    }
    // Host-side GTest.
    {
      "name" : "net_test_avrcp",
      "host" : true
    }
  ],
  "postsubmit": [
    {
      "name": "CtsDeqpTestCases",
      "options": [
        {
          // Use regex in include-filter which is supported in AndroidJUnitTest
          "include-filter": "dEQP-EGL.functional.color_clears.*"
        }
      ]
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

গুণাবলী সেট করুন

options অ্যাট্রিবিউটে অতিরিক্ত ট্রেডফেড কমান্ড লাইন বিকল্প রয়েছে।

tradefed.sh run commandAndExit [test_module] --help

Atest দিয়ে পরীক্ষা চালান

স্থানীয়ভাবে প্রি-সাবমিট পরীক্ষার নিয়মগুলি সম্পাদন করতে:

TEST_MAPPING ফাইল ধারণকারী ডিরেক্টরিতে যান।
কমান্ড চালান:
```
atest
```

স্ট্রাকচার সোর্স কোড

src
├── project_1
│   └── TEST_MAPPING
├── project_2
│   └── TEST_MAPPING
└── TEST_MAPPING

src/TEST_MAPPING এর বিষয়বস্তু:

{
  "presubmit": [
    {
      "name": "A"
    }
  ]
}

src/project_1/TEST_MAPPING এর বিষয়বস্তু :

{
  "presubmit": [
    {
      "name": "B"
    }
  ],
  "postsubmit": [
    {
      "name": "C"
    }
  ],
  "other_group": [
    {
      "name": "X"
    }
  ]}

src/project_2/TEST_MAPPING এর বিষয়বস্তু :

{
  "presubmit": [
    {
      "name": "D"
    }
  ],
  "import": [
    {
      "path": "src/project_1"
    }
  ]}

টার্গেট ডিরেক্টরি নির্দিষ্ট করুন

atest --test-mapping src/project_1

পোস্ট সাবমিট পরীক্ষার নিয়ম চালান

atest [--test-mapping] [src_path]:postsubmit

শুধুমাত্র এমন পরীক্ষা চালান যাতে কোনো ডিভাইসের প্রয়োজন হয় না

atest [--test-mapping] --host

পরীক্ষা গ্রুপ সনাক্ত করুন

atest --test-mapping src/project_1:all

সাবডিরেক্টরি অন্তর্ভুক্ত করুন

atest --include-subdir

লাইন-স্তরের মন্তব্য সমর্থিত

উদাহরণ:

{
  // For presubmit test group.
  "presubmit": [
    {
      // Run test on module A.
      "name": "A"
    }
  ]
}