ສັນຍາລັກ Gherkin

ເປັນຫຍັງຈຶ່ງໃຊ້ Gherkin

ໃນຫຼາຍໆທີມງານ, ນັກພັດທະນາຈັດການສະເປັກການທົດສອບດ້ວຍ code ໃນຂະນະທີ່ຝ່າຍທຸລະກິດຈັດການດ້ວຍເອກະສານພາສາຍີ່ປຸ່ນຫຼືອັງກິດແຍກຕ່າງຫາກ. ທຸກຄັ້ງທີ່ມີການປ່ຽນແປງສະເປັກ, ຈຳເປັນຕ້ອງອັບເດດທັງສອງຝ່າຍ ເຮັດໃຫ້ເກີດຄວາມຄາດເຄື່ອນສະສົມຂຶ້ນເລື້ອຍໆ.

Gherkin notation ແກ້ໄຂບັນຫານີ້ດ້ວຍວິທີການທີ່ເອີ້ນວ່າ "executable specification". ດ້ວຍ syntax ທີ່ໃກ້ຄຽງກັບພາສາທຳມະຊາດທີ່ຜູ້ຮັບຜິດຊອບດ້ານທຸລະກິດສາມາດອ່ານໄດ້, ໃນຂະນະດຽວກັນກໍ່ສາມາດ execute ເປັນ automated test ໄດ້ໂດຍກົງ. ເນື່ອງຈາກສະເປັກແລະ test code ຢູ່ໃນໄຟລ໌ດຽວກັນ, ຄວາມແຕກຕ່າງລະຫວ່າງທັງສອງຈຶ່ງເກີດຂຶ້ນຍາກໂດຍໂຄງສ້າງ.

Syntax ພື້ນຖານ

ໂຄງສ້າງທົ່ວໄປຂອງໄຟລ໌ .feature ມີດັ່ງນີ້.

Feature ສອດຄ່ອງກັບກຸ່ມຂອງໜ່ວຍຟັງຊັ່ນ, ສ່ວນ Scenario ສອດຄ່ອງກັບ test case ແຕ່ລະອັນ. ສາມາດເພີ່ມເງື່ອນໄຂດ້ວຍ And / But, ແລະສາມາດ parameterize ໄດ້ດ້ວຍ Scenario Outline + ຕາຕະລາງ Examples.

ໜຶ່ງໃນຈຸດເດັ່ນຄືຮອງຮັບພາສາທຳມະຊາດຫຼາຍກວ່າ 70 ພາສາລວມທັງພາສາຍີ່ປຸ່ນ, ແລະສາມາດ localize keyword ໄດ້ໂດຍກົງ.

ຄວາມສຳພັນກັບ BDD

Gherkin notation ເກີດຂຶ້ນຈາກ practice ຂອງ BDD (Behaviour-Driven Development). ໃນ BDD, ໃຫ້ຄວາມສຳຄັນກັບການອະທິບາຍ "ຊອບແວຄວນເຮັດຫຍັງ" ໃນຮູບແບບທີ່ຜູ້ມີສ່ວນໄດ້ສ່ວນເສຍທຸກຄົນສາມາດແບ່ງປັນໄດ້. Gherkin ເປັນການ standardize format ການອະທິບາຍດັ່ງກ່າວ, ໂດຍ framework ຢ່າງ Cucumber, Behave, ແລະ SpecFlow ຈະ parse ໄຟລ໌ Gherkin ແລ້ວ execute ການທົດສອບ.

ນັບຕັ້ງແຕ່ທີມຂອງຜູ້ຂຽນເລີ່ມຂຽນ acceptance test ດ້ວຍ Gherkin, ການສ້າງຄວາມເຫັນດີເຫັນພ້ອມໃນກອງປະຊຸມ review ລະຫວ່າງ QA ແລະນັກພັດທະນາວ່າ "ຖ້າ Scenario ນີ້ຜ່ານກໍ່ release ໄດ້" ໄດ້ໄວຂຶ້ນຢ່າງຫຼວງຫຼາຍ.

ຈຸດທີ່ຕ້ອງລະວັງໃນການນຳໃຊ້

ມັນບໍ່ແມ່ນວິທີແກ້ທຸກບັນຫາ. ຖ້າອອກແບບ granularity ຂອງ step definition (implementation code ທີ່ execute ຢູ່ເບື້ອງຫຼັງຂອງ Given/When/Then) ຜິດພາດ, step ທີ່ຄ້າຍຄືກັນຈະເພີ່ມຂຶ້ນຈຳນວນຫຼວງຫຼາຍ ເຮັດໃຫ້ຄ່າໃຊ້ຈ່າຍໃນການບຳລຸງຮັກສາສູງຂຶ້ນຢ່າງຫຼວງຫຼາຍ. ນອກຈາກນີ້, ການຂຽນ operation ລາຍລະອຽດຂອງ UI ໃນ Gherkin ທີລະຂັ້ນຕອນມີແນວໂນ້ມທີ່ຈະ verbose, ແລະໃນຫຼາຍກໍລະນີ, ການ apply ສະເພາະກັບການກວດສອບ business rule ແທນທີ່ຈະ Gherkin ize E2E test ທັງໝົດ ຈະໃຫ້ cost-effectiveness ທີ່ດີກວ່າ.