When you are writhing your testes, how deep do you go?
I'm about to start using behats e thinking abount how many scenarios I'll have.
If you think in a CRUD feature will we have ( I know this is not a cookbook)
C :
Submit without fill any field (with client validation) and check every single field was validated
Submit without fill any field (with server validation) and check every single field was validated
Test unique fields like email
Test masks, datepick, select2, etc.
Javascript html manipulation
Submit a valid form
R:
Check if "all" db lines are listed
Pagination ( first , previou , next and last page , number of lines per page )
Filtering and Ordering for every single filters and columns
U:
Show corect information for everything filed
+ repeat "C" testes
D:
Can't delete "undeliting" rows ( client side )
Can't delete "undeliting" rows ( server side )
Delete rows ( show confirmation message )
Of course it can be more complicatad than this, but we would have at least 20 scenarios.
My question is: Do you always do all "these" scenarios for every CRUD ?
I do, and it has saved my ass several times. One small little change in your code somewhere could lead to a small, undetected change elsewhere that could break something. I test everything that I possibly can so I can be sure that everything is working like I want it.
@zachleigh , nice!
Are you using behats , integrated or anything else ?
I'd like to add to this when you make tests it forces you to make you code testable. Which makes it better from design perspective. I've done many good architecture decisions while covering it with tests. Plus you feel way more confident when refactoring. Plus it saves you ton of time when you do enhancements to your code (remember complexity of you code grows over time).
@andremellow For my current project, Im using Integrated and some standard phpunit for unit tests. Im really liking Integrated. It makes it easy to test things from a user perspective.
@neomerx I couldnt agree more!
Do you use all types of tests? Unit, Functional, Acceptance, Integration tests?
@andremellow Usually validation test goes the other way around : you test if it works with valid data then check each rules one by one.
Then you can overtest if you test framework features. For example with pagination : you just have to test pagniate method is actually called. Then, the paginate method of laravel is already heavily tested, so you dont need to test if it actually returns a paginator with the expected items etc...
@Ruffles I see Unit test needed only if you have a kind complex function, otherwise the acceptance test will cover all.
If Acceptance does pass, all other kind of test will too, but if your unit test pass it doesn't mean the acceptance will. So I see acceptance as One All Soluction test.
Please or to participate in this conversation.