Use SQLite in memory, that is fast... External DB calls aren't fast at all. I expect lots of tests to finish in matter of seconds. Tests should check whatever is related to what you want to make sure is working (sorry for the ambiguous sentence). That means that if you need to test something is stored in the DB (I mean that is your intent) then go to the DB and check it. BUT! if you are checking a service (A) that uses another service (B) which does a DB request, you should mock B and not the DB for better tests isolation.
If the code already exists, and there are not tests, yea you're probably right about removing chunks of code. Better yet write the test first, see it fail, and then write the code to make it pass. That way you shouldn't have untested and unnecessary code. If that is not an option (the code is already written) start with reading the code and try to understand what it does, and add a test for that little by little, and use coverage to find untested branches in the code.
If the point is to convince someone to write tests, that is a helpful tip. In real world scenario I would never want to waste my time on checking things I don't understand why I need them.
Just to clarify, from my understanding Laravel ships with mocks (fakes) for internal features like events, storage, etc... Yea they're good for that they were intended to do, but still if I need to mock some library for a unit test, I would rather mock it right away without messing with Laravel at all...
TDD rules! write tests first!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Discussion on: Tips for testing web applications
For further actions, you may consider blocking this person and/or reporting abuse