1
00:00:06,550 --> 00:00:09,410
- So table tests are a very powerful way

2
00:00:09,410 --> 00:00:12,440
of writing uniTESTs when
you have a base code

3
00:00:12,440 --> 00:00:14,950
and you wanna throw a
lot of different input

4
00:00:14,950 --> 00:00:16,980
and expected output around it.

5
00:00:16,980 --> 00:00:18,730
So you don't have to write a whole bunch

6
00:00:18,730 --> 00:00:21,350
of test functions, we can
leverage one test function

7
00:00:21,350 --> 00:00:24,870
with a table of inputs and outputs

8
00:00:24,870 --> 00:00:26,850
and run that test all the way through.

9
00:00:26,850 --> 00:00:29,120
So let me show you a basic table test.

10
00:00:29,120 --> 00:00:30,680
Again we've got our _test file,

11
00:00:30,680 --> 00:00:32,520
we've got our test download function,

12
00:00:32,520 --> 00:00:35,600
our testing t pointer, and
this time if you notice,

13
00:00:35,600 --> 00:00:38,370
I have a variable here called tests,

14
00:00:38,370 --> 00:00:42,070
and it's based on this literal struct,

15
00:00:42,070 --> 00:00:44,360
or slice of these literal structs,

16
00:00:44,360 --> 00:00:45,360
we do this a lot right?

17
00:00:45,360 --> 00:00:47,150
I don't need a name type here.

18
00:00:47,150 --> 00:00:51,116
So I defined my input,
I defined my output,

19
00:00:51,116 --> 00:00:53,800
we're gonna use our URL,
I expect a status code,

20
00:00:53,800 --> 00:00:55,350
and now I could load this table

21
00:00:55,350 --> 00:00:57,220
with different scenarios, right?

22
00:00:57,220 --> 00:01:00,310
So here is the call to the rss feed,

23
00:01:00,310 --> 00:01:02,740
we expect a status, OK or 200,

24
00:01:02,740 --> 00:01:07,020
here is a call to a cnn rss feed

25
00:01:07,020 --> 00:01:10,370
that I've misspelled,
and therefore we expect

26
00:01:10,370 --> 00:01:13,430
a status 404, status not found.

27
00:01:13,430 --> 00:01:17,150
And as new test cases
arise, as we find bugs,

28
00:01:17,150 --> 00:01:18,580
instead of writing a new test function,

29
00:01:18,580 --> 00:01:21,970
we just throw more data at the table,

30
00:01:21,970 --> 00:01:23,600
and then it's really the same thing.

31
00:01:23,600 --> 00:01:26,800
It's giving the need to
test different content

32
00:01:26,800 --> 00:01:28,400
at different statuses, right?

33
00:01:28,400 --> 00:01:31,720
And this time before we
get into the when clause,

34
00:01:31,720 --> 00:01:34,496
we're gonna range over our table,

35
00:01:34,496 --> 00:01:37,270
picking out every piece
of input and output,

36
00:01:37,270 --> 00:01:39,050
and you can see we're
gonna range over tests,

37
00:01:39,050 --> 00:01:40,900
index i, tt.

38
00:01:40,900 --> 00:01:44,600
The one clause now is
displaying where we are

39
00:01:44,600 --> 00:01:47,880
in our data table,
including our test number,

40
00:01:47,880 --> 00:01:49,260
and then everything else is the same.

41
00:01:49,260 --> 00:01:51,160
We've got the get call, the close,

42
00:01:51,160 --> 00:01:52,810
and we check the status.

43
00:01:52,810 --> 00:01:55,430
So now if I want to check a 500,

44
00:01:55,430 --> 00:01:58,500
if I wanna check a 403,
if I wanna check a 203,

45
00:01:58,500 --> 00:02:02,160
whatever all the codes are,
I could just keep adding data

46
00:02:02,160 --> 00:02:04,580
and not just adding test functions.

47
00:02:04,580 --> 00:02:06,040
So let's run this, 'cause this is gonna

48
00:02:06,040 --> 00:02:08,740
run through two pieces of data here.

49
00:02:08,740 --> 00:02:11,870
I've already navigated into this folder,

50
00:02:11,870 --> 00:02:14,950
and so now what I can do is say go test,

51
00:02:14,950 --> 00:02:17,890
I'll use the -v because we
know it's gonna succeed,

52
00:02:17,890 --> 00:02:19,840
and I want you to see the output.

53
00:02:19,840 --> 00:02:21,740
And again what's nice about the output

54
00:02:22,644 --> 00:02:24,430
that I have here is you can see the run

55
00:02:24,430 --> 00:02:26,920
for the first piece of
data and what we're using

56
00:02:26,920 --> 00:02:29,100
here on test zero, you could see the run

57
00:02:29,100 --> 00:02:32,020
for the next piece of
data, and what we're doing,

58
00:02:32,020 --> 00:02:34,650
you see all the check boxes right there,

59
00:02:34,650 --> 00:02:36,150
and it's great, right?

60
00:02:36,150 --> 00:02:37,220
We got all the verbosity.

61
00:02:37,220 --> 00:02:39,300
So these table tests,
even though this took

62
00:02:39,300 --> 00:02:42,230
a little bit longer now,
it took almost a full

63
00:02:42,230 --> 00:02:44,250
second to run these two tests,

64
00:02:44,250 --> 00:02:46,243
these tests are running in series here,

65
00:02:47,801 --> 00:02:50,220
but at the end of the day,
I didn't have to write

66
00:02:50,220 --> 00:02:53,920
an extra test function,
I just used this table,

67
00:02:53,920 --> 00:02:57,170
and there's no formality
on what your table

68
00:02:57,170 --> 00:02:58,003
can look like.

69
00:02:58,003 --> 00:03:00,850
We tend to use it as a collection,

70
00:03:00,850 --> 00:03:02,550
because it's a collection of data,

71
00:03:02,550 --> 00:03:05,690
we tend to do this where
we are just defining

72
00:03:05,690 --> 00:03:07,870
our literal type, whatever that struct is

73
00:03:07,870 --> 00:03:09,180
for our inputs and our outputs,

74
00:03:09,180 --> 00:03:11,530
we make a slice of that
and that's what we're

75
00:03:11,530 --> 00:03:13,240
ranging over historically.

76
00:03:13,240 --> 00:03:15,010
But these are table tests in go,

77
00:03:15,010 --> 00:03:16,910
and you'll hear a lot of go developers

78
00:03:16,910 --> 00:03:18,793
love writing table tests.