- So table tests are a very powerful way
of writing uniTESTs when you have a base code
and you wanna throw a lot of different input
and expected output around it.
So you don't have to write a whole bunch
of test functions, we can leverage one test function
with a table of inputs and outputs
and run that test all the way through.
So let me show you a basic table test.
Again we've got our _test file,
we've got our test download function,
our testing t pointer, and this time if you notice,
I have a variable here called tests,
and it's based on this literal struct,
or slice of these literal structs,
we do this a lot right?
I don't need a name type here.
So I defined my input, I defined my output,
we're gonna use our URL, I expect a status code,
and now I could load this table
with different scenarios, right?
So here is the call to the rss feed,
we expect a status, OK or 200,
here is a call to a cnn rss feed
that I've misspelled, and therefore we expect
a status 404, status not found.
And as new test cases arise, as we find bugs,
instead of writing a new test function,
we just throw more data at the table,
and then it's really the same thing.
It's giving the need to test different content
at different statuses, right?
And this time before we get into the when clause,
we're gonna range over our table,
picking out every piece of input and output,
and you can see we're gonna range over tests,
index i, tt.
The one clause now is displaying where we are
in our data table, including our test number,
and then everything else is the same.
We've got the get call, the close,
and we check the status.
So now if I want to check a 500,
if I wanna check a 403, if I wanna check a 203,
whatever all the codes are, I could just keep adding data
and not just adding test functions.
So let's run this, 'cause this is gonna
run through two pieces of data here.
I've already navigated into this folder,
and so now what I can do is say go test,
I'll use the -v because we know it's gonna succeed,
and I want you to see the output.
And again what's nice about the output
that I have here is you can see the run
for the first piece of data and what we're using
here on test zero, you could see the run
for the next piece of data, and what we're doing,
you see all the check boxes right there,
and it's great, right?
We got all the verbosity.
So these table tests, even though this took
a little bit longer now, it took almost a full
second to run these two tests,
these tests are running in series here,
but at the end of the day, I didn't have to write
an extra test function, I just used this table,
and there's no formality on what your table
can look like.
We tend to use it as a collection,
because it's a collection of data,
we tend to do this where we are just defining
our literal type, whatever that struct is
for our inputs and our outputs,
we make a slice of that and that's what we're
ranging over historically.
But these are table tests in go,
and you'll hear a lot of go developers
love writing table tests.