3 ms·
> "Sql? It does all the wrong things; singletons, no testability, cgo for implementations, side effects and you have to use every database differently based on
by ZenoArrow 10y ago
> "Sql?
It does all the wrong things; singletons, no testability, cgo for implementations, side effects and you have to use every database differently based on their individual semantics."
SQL has its flaws, but it is testable. The testing approaches available vary depending on the implementation. For example, can write unit tests for SQL Server (using tSQLt, to give one example: http://tsqlt.org/ http://tsqlt.org/ ).
- shadowmint 10y agoyeah no. If you have an interface and you need a separate test suite for each implementation of that interface, it's a terrible interface.
- ZenoArrow 10y agoThe point is, there's nothing inherent in the design of SQL that stops it being testable, it just hasn't reached the SQL standards yet. Plus, there are plenty of ways to test standard SQL, you can easily do so through stored procedures.
- shadowmint 10y agoI'm not talking about SQL in general, I'm talking about the golang sql module. Read this if you think I'm wrong: https://github.com/bradfitz/go-sql-test/blob/master/src/sqltest/sql_test.go#L149 https://github.com/bradfitz/go-sql-test/blob/master/src/sqlt... Great abstraction, right? Love how you have to mangle the raw SQL right? no. It's a bad abstraction. When you test the implementation and you have to know the details of the implementation to test it, that's like, the definition of a bad abstraction. It is what it is. ...and ultimately, we're stuck with it because its part of the standard library. /shrug