Bạn vui mừng về ứng dụng bạn đã tạo ra. Chỉ có một vấn đề - bạn không có bất kỳ bài kiểm tra nào. Bạn muốn viết nó bằng Phát triển theo hướng thử nghiệm, nhưng bạn không biết bắt đầu từ đâu. Vì vậy, bạn đang bị mắc kẹt. Bạn đi đâu từ đây? Làm cách nào để bạn chuyển từ ứng dụng không có kiểm tra sang viết ứng dụng của mình bằng TDD?
Kiểm tra mã bạn đã có
Bạn có một loạt mã mà không có bài kiểm tra nào. Nhưng điều đó không có nghĩa là bạn không thể viết các bài kiểm tra của mình ngay bây giờ , so với mã hiện có. Vì vậy, hãy bắt đầu kiểm tra mã bạn đã có, để đảm bảo mã của bạn hoạt động theo cách bạn mong đợi.
Đó không phải là TDD. Nhưng việc kiểm tra mã hiện có sẽ giúp bạn học hỏi TDD :
-
Bạn thực hành suy nghĩ về các trường hợp cạnh và điều kiện lỗi.
Để viết các bài kiểm tra mà không mất nhiều năm để kiểm tra mọi đầu vào có thể, bạn phải nghĩ về nơi mã có nhiều khả năng bị hỏng nhất. Nếu phương pháp bạn đang thử nghiệm có một chuỗi, điều gì sẽ xảy ra nếu bạn chuyển cho nó một ký hiệu? Điều gì xảy ra nếu bạn vượt qua nó
nil? Và nếu bạn đang thử nghiệm một hàm phân chia các số, tốt hơn bạn nên thử nghiệm nó với 0. Nhưng có thể bạn không cần kiểm tra nó với 1 và 2.Sau khi viết đủ các bài kiểm tra, bạn sẽ bắt đầu dự đoán vị trí mà các phương pháp của bạn có nhiều khả năng bị lỗi nhất. Và khi bạn bắt đầu TDDing, bạn có thể sử dụng kỹ năng này để viết các bài kiểm tra mạnh mẽ buộc mã của bạn phải xử lý các trường hợp cạnh của bạn tốt hơn.
-
Bạn thực hành viết các bài kiểm tra có cấu trúc tốt.
Khi bạn viết các bài kiểm tra sau khi thực tế, bạn có thể thử các mẫu khác nhau để cấu trúc các bài kiểm tra đó. Mã bạn đang kiểm tra đã có ở đó, vì vậy bạn có thể tập trung vào bài kiểm tra của mình và cách nó được viết. Và khi bạn học được một số mẫu hay, bạn sẽ viết các bài kiểm tra tốt hơn khi không có mã để dựa vào.
-
Bạn phát hiện ra những điều khiến mã khó kiểm tra.
Khi bạn viết nhiều bài kiểm tra hơn, bạn sẽ bắt đầu nhận ra những khu vực nào trong hệ thống của bạn sẽ khó kiểm tra nhất. Khi bạn nhận thấy những khu vực đó, bạn có thể đánh dấu chúng như những nơi cần tái cấu trúc. Tốt hơn nữa, bạn sẽ bắt đầu viết nhiều mã có thể kiểm tra hơn trong lần đầu tiên.
Khi bạn biết mã dễ kiểm tra trông như thế nào, bạn có thể TDD các API dễ kiểm tra với kiến thức đó. Và điều đó sẽ giúp bạn xây dựng ứng dụng của mình nhanh hơn.
Dễ dàng chuyển sang TDD
Bạn có thể sử dụng chế độ kiểm tra sau để xây dựng các kỹ năng giúp bạn học TDD. Nhưng cuối cùng bạn vẫn muốn TDD các phần ứng dụng của mình. Và có một cách đơn giản để dễ dàng sử dụng TDD và vẫn dựa trên mã hiện có:viết kiểm tra hồi quy.
Kiểm tra hồi quy giúp bạn không vi phạm mã mà bạn đã sửa. Y tưởng nay đơn giản qua. Bất cứ khi nào bạn nghe về một lỗi, thay vì nhấp vào trong trình duyệt để tạo lại lỗi đó:
- Viết một bài kiểm tra không đạt để tái tạo lỗi.
- Chạy thử nghiệm và đảm bảo rằng chúng không thành công (vì lỗi đó vẫn tồn tại).
- Sửa lỗi theo cách đơn giản nhất có thể.
- Chạy thử nghiệm và đảm bảo rằng họ sẽ vượt qua.
- Trình tái cấu trúc bản sửa lỗi của bạn, nếu cần.
Điều này dễ dàng hơn nhiều so với TDDing một hệ thống mới từ đầu, bởi vì bạn chỉ đang thử nghiệm lái xe thay đổi đối với mã đã có ở đó. Bạn xây dựng thói quen “Red, Green, Refactor” đó là vòng lặp thiết yếu của TDD. Và từ đây, TDD chỉ còn một bước ngắn hơn là cố gắng đi thẳng đến TDD mà không cần kiểm tra.
Từ không sang TDD
Một ứng dụng không có thử nghiệm không phải là một nơi tồi để bắt đầu. Khi bạn kiểm tra mã hiện có, bạn sẽ học được rất nhiều điều cần thiết để viết các bài kiểm tra TDD tốt. Thử nghiệm sau dễ dàng hơn TDD lúc đầu, vì bạn không cần phải tưởng tượng ra các API mà bạn chưa biết cách thiết kế. Và khi bạn quyết định đưa TDD vào ứng dụng của mình, bạn có thể dễ dàng thực hiện nó bằng các bài kiểm tra hồi quy.
Vì vậy, nếu bạn không biết cách TDD hệ thống mà bạn đang tưởng tượng, hãy tiếp tục viết các bài kiểm tra. Ngay cả khi bạn phải viết mã trước.