Skip to content
New issue

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

database/sql: resurrect go-sql-test with modern container things #19886

Open
bradfitz opened this issue Apr 8, 2017 · 7 comments
Open

database/sql: resurrect go-sql-test with modern container things #19886

bradfitz opened this issue Apr 8, 2017 · 7 comments

Comments

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Apr 8, 2017

https://github.com/bradfitz/go-sql-test was an effort to automate testing of database/sql against all of the out-of-tree database drivers.

Nowadays there are many more drivers: https://golang.org/wiki/SQLDrivers

But https://github.com/bradfitz/go-sql-test is old & neglected & broken. It predates Dockers (by about a year).

It should use containers and be runnable by anybody without a bunch of setup work.

Anybody have time to help?

/cc @kardianos

@bradfitz bradfitz added this to the Unreleased milestone Apr 8, 2017
@AlekSi

This comment has been minimized.

Copy link
Contributor

@AlekSi AlekSi commented Apr 10, 2017

Wanted to write about this for some time. I used self-hosted Drone CI with 60 combinations for my ORM with great success: https://github.com/go-reform/reform/blob/v1-stable/.drone.yml#L64.

What kind of infrastructure you want to use to run tests?

@xfernando

This comment has been minimized.

Copy link

@xfernando xfernando commented Aug 25, 2017

Hey @bradfitz, I saw this issue with HelpWanted so I started doing some work on this and what I've done so far is available here: https://github.com/xfernando/go-db-driver-tests. I have tests running and passing for two mysql drivers and two postgres drivers with everything (including the tests) running on docker containers.

I thought it'd be too much work trying to get your old repo running so I started a fresh one and copied some of your old code and refactored things a bit so it'd be easier to add tests for more drivers.

@bradfitz

This comment has been minimized.

Copy link
Contributor Author

@bradfitz bradfitz commented Aug 25, 2017

@kardianos owns database/sql these days, and especially so while I'm on paternity leave.

@xfernando

This comment has been minimized.

Copy link

@xfernando xfernando commented Aug 29, 2017

@kardianos Is this something you need someone to work on? I have some time to put into it but I need to know if I'm going about it the right way.

@kardianos

This comment has been minimized.

Copy link
Contributor

@kardianos kardianos commented Aug 31, 2017

@xfernando I'm not too concerned with some implementation details at the moment. I think most of the current go build testing is run on k8s.

If I'm dreaming I would imagine being able to clone a driver repo at a specific branch, or PR and run a test against it. I would record the driver run output and store it either to a local directory or to GCE object storage. Record the location of the driver run output in a central list.

Perhaps a more modest proposal would be to spin up an image/pod once a day (as a batch a job), have it pull the latest drivers from source master, and test them and post the results to GCE object storage/file location. The output should include the git revision of each driver used and import path. If that is working, we could ask if the Go project would be willing to schedule the image to run once a day as a job.

@xfernando

This comment has been minimized.

Copy link

@xfernando xfernando commented Aug 31, 2017

@kardianos Option 2 is closer to what I've done.

I have a Dockerfile that builds an image with driver prerequisites (such as libpq-dev), uses go get to get the latest version of the drivers and runs go test -v. I have a a docker-compose.yml file that spins up the database containers needed for the tests to run.

Here's the output of the container that runs the tests (I added the printing the driver's revision per your suggestion).

⇒  docker-compose logs -f godbtests
Attaching to godbtests
godbtests    | === RUN   TestMySQLDrivers
godbtests    | === RUN   TestMySQLDrivers/gomysql:_TXQuery
godbtests    | === RUN   TestMySQLDrivers/gomysql:_Blobs
godbtests    | === RUN   TestMySQLDrivers/gomysql:_ManyQueryRow
godbtests    | === RUN   TestMySQLDrivers/gomysql:_PreparedStmt
godbtests    | === RUN   TestMySQLDrivers/mymysql:_TXQuery
godbtests    | === RUN   TestMySQLDrivers/mymysql:_Blobs
godbtests    | === RUN   TestMySQLDrivers/mymysql:_ManyQueryRow
godbtests    | === RUN   TestMySQLDrivers/mymysql:_PreparedStmt
godbtests    | --- PASS: TestMySQLDrivers (13.08s)
godbtests    | 	mysql_test.go:81: github.com/go-sql-driver/mysql revision: 26471af196a17ee75a22e6481b5a5897fb16b081
godbtests    |     --- PASS: TestMySQLDrivers/gomysql:_TXQuery (0.46s)
godbtests    |     --- PASS: TestMySQLDrivers/gomysql:_Blobs (0.48s)
godbtests    |     --- PASS: TestMySQLDrivers/gomysql:_ManyQueryRow (5.01s)
godbtests    |     --- PASS: TestMySQLDrivers/gomysql:_PreparedStmt (1.50s)
godbtests    | 	mysql_test.go:87: github.com/ziutek/mymysql revision: 1d19cbf98d83564cc561192ae7d7183d795f7ac7
godbtests    |     --- PASS: TestMySQLDrivers/mymysql:_TXQuery (0.51s)
godbtests    |     --- PASS: TestMySQLDrivers/mymysql:_Blobs (0.42s)
godbtests    |     --- PASS: TestMySQLDrivers/mymysql:_ManyQueryRow (3.35s)
godbtests    |     --- PASS: TestMySQLDrivers/mymysql:_PreparedStmt (1.34s)
godbtests    | === RUN   TestPostgresDrivers
godbtests    | === RUN   TestPostgresDrivers/pgx:_TXQuery
godbtests    | === RUN   TestPostgresDrivers/pgx:_Blobs
godbtests    | === RUN   TestPostgresDrivers/pgx:_ManyQueryRow
godbtests    | === RUN   TestPostgresDrivers/pgx:_PreparedStmt
godbtests    | === RUN   TestPostgresDrivers/pq:_TXQuery
godbtests    | === RUN   TestPostgresDrivers/pq:_Blobs
godbtests    | === RUN   TestPostgresDrivers/pq:_ManyQueryRow
godbtests    | === RUN   TestPostgresDrivers/pq:_PreparedStmt
godbtests    | --- PASS: TestPostgresDrivers (11.43s)
godbtests    | 	postgres_test.go:87: github.com/jackc/pgx revision: 47c0e9cbac744e0d1b71b155fc1d222cfef37140
godbtests    |     --- PASS: TestPostgresDrivers/pgx:_TXQuery (0.09s)
godbtests    |     --- PASS: TestPostgresDrivers/pgx:_Blobs (0.13s)
godbtests    |     --- PASS: TestPostgresDrivers/pgx:_ManyQueryRow (0.32s)
godbtests    |     --- PASS: TestPostgresDrivers/pgx:_PreparedStmt (5.16s)
godbtests    | 	postgres_test.go:93: github.com/lib/pq revision: e42267488fe361b9dc034be7a6bffef5b195bceb
godbtests    |     --- PASS: TestPostgresDrivers/pq:_TXQuery (0.09s)
godbtests    |     --- PASS: TestPostgresDrivers/pq:_Blobs (0.16s)
godbtests    |     --- PASS: TestPostgresDrivers/pq:_ManyQueryRow (5.14s)
godbtests    |     --- PASS: TestPostgresDrivers/pq:_PreparedStmt (0.34s)
godbtests    | PASS
godbtests    | ok  	app/sqltest	24.522s
godbtests exited with code 0
@kardianos

This comment has been minimized.

Copy link
Contributor

@kardianos kardianos commented Aug 31, 2017

That output looks great, for at least a first pass. I'll ping go-dev and see if they would be willing to allocate some CPU time to test this, and if so, what a good environment would be to run this in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.