4 ms·
>Okay. The biggest problem I see with people trying to write unit tests is that they don’t want to change how they write code. They just want tests for it. It’s
by crdoconnor 9y ago
>Okay. The biggest problem I see with people trying to write unit tests is that they don’t want to change how they write code. They just want tests for it. It’s like watching an OO person try their hardest to write OO code in a functional language.
I've seen what happens when a developer tries to abstract away a database in a database driven app so it can be "better unit tested". It's a goddamn mess.
If your app relies heavily on using a database, your app naturally integrates with a database then it makes no sense to test without it. You are intentionally avoiding testing in a way that will pick up bugs.
>Unit tests run faster, are written faster
Unit tests test less realistically. That means they don't catch bugs integration tests do.
They also often take longer to write and are more tightly coupled.
How coding this way came to be seen as a best practice is beyond me. Tight coupling and premature optimization is usually seen as bad practice in other areas.
- piaste 9y ago> If your app relies heavily on using a database, your app naturally integrates with a database then it makes no sense to test without it. You are intentionally avoiding testing in a way that will pick up bugs. Also, with Docker it's now actually feasible to automatically test against a real database at a reasonable speed. A Postgres container spins up in a couple of seconds, a SQL Server one in a little over four.
- crdoconnor 9y agoThat has nothing to do with docker, really. I run postgres standalone on my laptop and it starts in < 1 second.
- GordonS 9y agoI guess they meant so your tests can start with a blank or reproducible state. But you can of course achieve the same by running a script before your tests start. There are also some frameworks for doing this sort of thing too, such as Fixie for .NET
- hinkley 9y agoDrop-create scripts! One of my first epiphanies in the testing world.
- kakwa_ 9y agoCreate only scripts can also be great in the right context. Namely a context like travis-ci where you get a new clean environment each time. Personally, I've develop few libraries/web UIs that relies on external software like a DNS server or an ldap directory. And for those, I've a quick and dirty shell script that deploys bind/OpenLDAP. It's far easier, faster and more accurate than mocking. For example, what comes to my mind is the testing I do for all the SSL/TLS modes I support (SSL, StartTLS, certificate check disable or not, etc) in my ldap web application. Travis also has available services in their build envs (stuff like redis, mongodb, mysql, cassandra...).
- crdoconnor 9y agoI do this with rsync to restore a snapshot of the database data folder.
- piaste 9y agoI've done "write a script to reset the database" before, although not for Pgsql. The effort and potential snags involved make it nowhere near as trivial as docker rm && docker run. There are also other scenarios that become really simple with disposable DB instances. Want to test a remote data transfer feature? Just spin up two databases.
- deleted 9y ago[deleted]
- piaste 9y agoSure, but I presume that doesn't include installation time.
- hinkley 9y agoIn another thread I talk about splitting deciding from doing and I find that strikes a very easy balance for database heavy code. Unit tests for the logic and just concede the data transport to higher level tests. Preferably with a local database full of test fixtures.