TDD

RED → GREEN → Refactor

ຂັ້ນຕອນຂອງ TDD ແມ່ນງ່າຍດາຍຫຼາຍ.

ກ່ອນອື່ນ, ຂຽນພຶດຕິກຳທີ່ຄາດຫວັງຂອງຟັງຊັນທີ່ຈະ implement ເປັນ test. ແນ່ນອນວ່າ test ຈະລົ້ມເຫລວ (RED). ຕໍ່ມາ, ຂຽນ code ຂັ້ນຕ່ຳສຸດເພື່ອໃຫ້ test ຜ່ານ (GREEN). ສຸດທ້າຍ, ຈັດລະບຽບ code ໂດຍບໍ່ປ່ຽນແປງພຶດຕິກຳ (Refactor). ສືບຕໍ່ວຽນ 3 ຂັ້ນຕອນນີ້ໃນຮອບສັ້ນໆ ຈາກສອງສາມນາທີຫາສິບກວ່ານາທີ.

Test ໃນຖານະເຄື່ອງມືອອກແບບ

ຖ້າເຂົ້າໃຈ TDD ວ່າເປັນ "ວິທີການ test" ກໍຈະເຂົ້າໃຈຜິດຈາກແກ່ນແທ້ຂອງມັນ. ການຂຽນ test ກ່ອນຈະກຳນົດ interface ຂອງຟັງຊັນ (argument ແລະ return value) ກ່ອນທີ່ຈະ implement. ເນື່ອງຈາກອອກແບບ API ຈາກມຸມມອງຂອງຝ່າຍທີ່ເອີ້ນໃຊ້, interface ທີ່ໃຊ້ງານຍາກຈຶ່ງເກີດຂຶ້ນໄດ້ຍາກ. ແຮງຈູງໃຈທີ່ Kent Beck ສະເໜີ TDD ກໍບໍ່ແມ່ນການເພີ່ມ test coverage ແຕ່ແມ່ນການປັບປຸງຄຸນນະພາບການອອກແບບ.

ການໃຊ້ຮ່ວມກັບ Unit Test

Test ສ່ວນໃຫຍ່ທີ່ຂຽນໃນ TDD ຈະກາຍເປັນ unit test. ຢ່າງໃດກໍຕາມ, TDD ແມ່ນວິທີການກ່ຽວກັບ "ເວລາໃດຈຶ່ງຂຽນ test" ໃນຂະນະທີ່ unit test ແມ່ນເລື່ອງຂອງ scope ກ່ຽວກັບ "ຈະ test ຫຍັງ". ພາຍໃນຮອບຂອງ TDD ກໍສາມາດຂຽນ test ທີ່ທຽບເທົ່າ functional test ໄດ້, ແລະ ກໍສາມາດຂຽນ unit test ໂດຍບໍ່ໃຊ້ TDD ກໍໄດ້.

ຄວາມສຳພັນເສີມກັນກັບ ATDD

ໃນຂະນະທີ່ ATDD ຮັບປະກັນຄວາມຖືກຕ້ອງຂອງ business requirement ຈາກພາຍນອກ, TDD ສ້າງຄວາມຖືກຕ້ອງຂອງ internal implementation ຈາກພາຍໃນ. ໃນລະດັບ project ທັງໝົດ, ໂຄງສ້າງສອງຊັ້ນທີ່ກຳນົດ acceptance criteria ດ້ວຍ ATDD ແລ້ວ implement ຟັງຊັນແຕ່ລະອັນດ້ວຍ TDD ເພື່ອຕອບສະໜອງ criteria ດັ່ງກ່າວ ແມ່ນຮູບແບບທີ່ດີທີ່ສຸດ.