We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
今天在laravel中學習到根據一個情況就編寫一個測試,逐步地把一個功能所要能處理的每個情況都寫成一個test,如此在新加情況處裡的時候,便能知道前者以處理好的情況有沒有因此壞掉
發想 : 連結到前端vue開發,資料時常是從後端或是api取得,資料量與結構時常是龐大的,在嘗試著把功能做出來(從畫面顯示來檢測是否做對了)之前,自己也沒辦法完全掌握該方法會產出什麼樣的資料,因此難以用TDD的方法開發,不過還是可以變通成在自己檢查"覺得"功能作對時,把該資料結構保存,並在這時亡羊補牢的加上test,至少讓程式開發還是有test的保護。
如果前端能像後端laravel 有factory的工具,或許就還是能以TDD的方式進行開發
The text was updated successfully, but these errors were encountered:
No branches or pull requests
今天在laravel中學習到根據一個情況就編寫一個測試,逐步地把一個功能所要能處理的每個情況都寫成一個test,如此在新加情況處裡的時候,便能知道前者以處理好的情況有沒有因此壞掉
發想 : 連結到前端vue開發,資料時常是從後端或是api取得,資料量與結構時常是龐大的,在嘗試著把功能做出來(從畫面顯示來檢測是否做對了)之前,自己也沒辦法完全掌握該方法會產出什麼樣的資料,因此難以用TDD的方法開發,不過還是可以變通成在自己檢查"覺得"功能作對時,把該資料結構保存,並在這時亡羊補牢的加上test,至少讓程式開發還是有test的保護。
如果前端能像後端laravel 有factory的工具,或許就還是能以TDD的方式進行開發
The text was updated successfully, but these errors were encountered: