ຄຳຖາມທີ່ພົບເລື້ອຍ

ຂ້ອຍຄວນທົດສອບແພັກເກດຂອງຂ້ອຍບໍ່?

ແນ່ນອນວ່າເຈົ້າຄວນເຮັດ!

ຂ້ອຍຈະຂໍຄວາມຊ່ວຍເຫຼືອໄດ້ແນວໃດ?

ນຳໃຊ້ ຊ່ອງ #fedora-ci ໃນ Matrix.

ເປັນຫຍັງຈຶ່ງບໍ່ຄວນເພິ່ງພາ %check ພຽງຢ່າງດຽວ?

%check ແລະ ການທົດສອບທີ່ເຮັດວຽກໃນ CI pipeline ແມ່ນເປັນສ່ວນເສີມໃຫ້ກັນແລະກັນ. %check ຊ່ວຍໃຫ້ສາມາດກວດສອບຫຼາຍໆຢ່າງໃນລະຫວ່າງການສ້າງ (build time) ແຕ່ມັນຈະບໍ່ກວດພົບ ສິ່ງທີ່ຈຳເປັນຕ້ອງມີ (requirement) ທີ່ຂາດໄປ, ໄຟລ໌ການຕັ້ງຄ່າທີ່ຫາຍໄປ ແລະ ສະຖານະການໃນລັກສະນະນີ້ ເຊິ່ງ CI pipeline ຈະສາມາດທົດສອບ ແລະ ຄົ້ນຫາໄດ້. ພວກເຮົາສາມາດເບິ່ງໄດ້ວ່າ %check ແມ່ນ ການທົດສອບແບບໜ່ວຍຍ່ອຍ (unit-test) (ເຊິ່ງແພັກເກດຄືໜ່ວຍຍ່ອຍ) ທຽບກັບການທົດສອບແບບປະສົມປະສານ (integration tests) ບ່ອນທີ່ການທົດສອບຖືກເຮັດວຽກໃນທົ່ວທັງລະບົບປະຕິບັດການ ຄືກັນກັບຕອນທີ່ພວກເຮົາ ແຈກຢາຍໃຫ້ຜູ້ໃຊ້. ດັ່ງນັ້ນ CI pipeline ຈະສາມາດຊອກຫາຂໍ້ຜິດພາດໃນການເຮັດວຽກຮ່ວມກັນ (integration bugs) ທີ່ສ່ວນຂອງ %check ບໍ່ສາມາດເຮັດໄດ້.

ຂ້ອຍຄວນເກັບການທົດສອບຂອງຂ້ອຍໄວ້ໃສ?

ມີຫຼາຍທາງເລືອກໃນການເກັບກຳລະຫັດການທົດສອບ. ນີ້ແມ່ນຂໍ້ດີ ແລະ ຂໍ້ເສຍທີ່ສຳຄັນຂອງແຕ່ລະວິທີ: ລະຫັດການທົດສອບໃນ dist git rpms namespace ແມ່ນຖືກແຍກສາຂາ (branched) ໄປພ້ອມກັບໄຟລ໌ spec ແລະ ສາມາດສະທ້ອນເຖິງການເຮັດວຽກໄດ້ຢ່າງໃກ້ຊິດ. ການທົດສອບທີ່ໃຊ້ໃນຫຼາຍພາກສ່ວນ ຫຼື ຫຼາຍລຸ້ນຂອງ OS ສາມາດເກັບໄວ້ໃນ dist git test namespace ເພື່ອແບ່ງປັນລະຫັດການທົດສອບ ແລະ ຫຼຸດຜ່ອນການບຳລຸງຮັກສາ. ການດຶງເອົາການທົດສອບຈາກ upstream project git ກໍສາມາດເຮັດໄດ້ ແລະ ຮອງຮັບໂດຍ standard-test-roles (source role). ເພື່ອປ້ອງກັນຄວາມລົ້ມເຫຼວຂອງການທົດສອບທີ່ບໍ່ຄາດຄິດ ທີ່ເກີດຈາກການປ່ຽນແປງຂອງຕົ້ນທາງ (upstream), ບາງຄັ້ງການອ້າງອີງເຖິງ commit ໃດໜຶ່ງໂດຍສະເພາະ ແມ່ນດີກວ່າການອ້າງອີງຕາມສາຂາ (branch). ການທົດສອບທີ່ເປີດໃຊ້ໃນ make check ຈະຖືກປະຕິບັດໃນສະພາບແວດລ້ອມທີ່ຕ່າງກັນ (buildroot). ສິ່ງນີ້ດີສຳລັບການທົດສອບແບບໜ່ວຍຍ່ອຍ (unit tests) ແຕ່ບໍ່ແນະນຳສຳລັບການທົດສອບແບບ Tier 1 ໃໝ່. ເປີດໃຊ້ 'make check' ໃນ tests.yml ສະເພາະຕອນທີ່ທົດສອບ rpm ທີ່ຕິດຕັ້ງແລ້ວເທົ່ານັ້ນ.