chapter-12.srt

1
00:00:00,000 --> 00:00:03,588
Chapter 12.
Returning fresh mtime from a regenerated Target.

2
00:00:04,057 --> 00:00:08,777
JC: If we go back to our code.

3
00:00:09,080 --> 00:00:15,965
What do we need to do? We've got
these mtimes so we need to store that.

4
00:00:18,160 --> 00:00:20,754
Ensure updated dependencies.

5
00:00:20,857 --> 00:00:25,691
We've said in our test that calling build
on a dependency will return its mtime.

6
00:00:25,690 --> 00:00:37,074
So let's store that in here when we build the
dependencies and call map so we get the values.

7
00:00:39,748 --> 00:00:54,217
And then here we can say "return unless" any of
the dependent times are greater than our own.

8
00:00:57,257 --> 00:01:00,285
I think that will be OK.

9
00:01:00,502 --> 00:01:04,982
What I do need to do for this to work...

10
00:01:05,337 --> 00:01:08,605
The build method will need to return mtime.

11
00:01:08,600 --> 00:01:13,462
But I haven't written a test that requires that yet.

12
00:01:13,630 --> 00:01:20,262
I'm just thinking how I would force myself
to do that, but we'll get to that in a second.

13
00:01:20,620 --> 00:01:25,040
"undefined method `>' for nil:NilClass"

14
00:01:25,070 --> 00:01:30,560
So that must mean that I've
stubbed mtime to somehow return (hmm)...

15
00:01:31,302 --> 00:01:35,017
So this is Target spec 33.

16
00:01:36,194 --> 00:01:39,954
What's going on in there?

17
00:01:42,205 --> 00:01:49,970
Oh yes, in this test those build
targets are not returning anything.

18
00:01:50,388 --> 00:01:54,388
TS: So they're getting nil back and
then trying to compare it to something.

19
00:01:54,400 --> 00:02:02,971
JC: Exactly. I think this is the point where I need
to put a value that actually makes sense in here.

20
00:02:03,100 --> 00:02:07,600
[Silence]

21
00:02:07,885 --> 00:02:10,937
Now everything passes.

22
00:02:14,388 --> 00:02:17,417
This is a bit of an illusion because it doesn't (hmm)...

23
00:02:17,474 --> 00:02:24,640
I'm actually surprised that the integration test
works because build isn't returning the mtime.

24
00:02:24,777 --> 00:02:29,462
[James thinks]

25
00:02:29,828 --> 00:02:36,034
TS: It's the integration test of the previous
behaviour that you're expecting to break?

26
00:02:36,170 --> 00:02:38,971
JC: Yes.

27
00:02:39,325 --> 00:02:43,222
That's probably because in the integration
test we're building things that don't exist.

28
00:02:43,234 --> 00:02:46,000
So it isn't hitting that code path.

29
00:02:47,142 --> 00:02:51,508
TS: So we don't have an integration
test for this laziness behaviour right?

30
00:02:51,500 --> 00:02:52,674
JC: No.

31
00:02:52,760 --> 00:02:55,085
Dependent targets.

32
00:02:55,360 --> 00:03:01,485
[James thinks]

33
00:03:02,034 --> 00:03:03,360
When one target depends on another...

34
00:03:03,360 --> 00:03:13,942
We could put a context in here that creates one.txt
and then sees if the second one will build.

35
00:03:14,260 --> 00:03:25,440
[saying what he's typing]

36
00:03:30,620 --> 00:03:38,102
Let's just make it include one rather than
whatever the files it was previously derived from are.

37
00:03:39,782 --> 00:03:44,822
No let's not do that. I don't want this test
to get into setting mtimes on various files.

38
00:03:44,820 --> 00:03:48,731
They're going to be created in a certain order.

39
00:03:48,770 --> 00:03:53,222
But the time resolution on those time
stamps on the file-system is only a second.

40
00:03:53,268 --> 00:03:59,920
So sometimes, depending on whether your
test execution overlaps a second boundary,

41
00:03:59,954 --> 00:04:05,577
there will sometimes be the same value and
sometimes not. The ordering is not predictable.

42
00:04:06,571 --> 00:04:18,651
To be safe, I'm going to make this have the value
that it would have if you had built it from source.

43
00:04:19,280 --> 00:04:24,628
Builds the final target successfully.

44
00:04:26,000 --> 00:04:32,022
I suppose successfully is implicit
when you're writing any sort of test but...

45
00:04:32,742 --> 00:04:35,645
Yeah...

46
00:04:37,634 --> 00:04:40,662
I'll just do that.

47
00:04:41,660 --> 00:04:50,491
This is still saying when you build the second
target it should have that content based on that.

48
00:04:50,525 --> 00:05:01,302
But this ought to trigger the
first target to try to check the...

49
00:05:02,570 --> 00:05:08,617
No, the first target will try to check the
mtimes of the files a and b that it depends on.

50
00:05:08,650 --> 00:05:14,674
and it will get nil from their build
methods, so this should fall over.

51
00:05:15,020 --> 00:05:17,577
Yes, so the same error out of that.

52
00:05:17,600 --> 00:05:20,491
TS: So this is not yet a test
of the laziness functionality,

53
00:05:20,525 --> 00:05:24,388
but it is exercising more of the code
than the previous integration test was?

54
00:05:24,380 --> 00:05:33,954
JC: Yes. That integration test makes sure
that you can build a partially built system.

55
00:05:34,050 --> 00:05:40,262
It means you need to test
that build returns the mtime.

56
00:05:44,000 --> 00:05:55,028
Going back to our unit tests, where did
we have something when there are dependencies?

57
00:05:55,588 --> 00:06:01,085
This doesn't necessarily mean
there are dependencies.

58
00:06:01,080 --> 00:06:03,154
There's actually two cases for this.

59
00:06:03,170 --> 00:06:07,714
If the file already exists and is up
to date it should return its existing mtime.

60
00:06:07,725 --> 00:06:13,965
but if you had to rebuild it, it
should return time.now, I guess.

61
00:06:14,060 --> 00:06:20,274
So we can build those into here.

62
00:06:20,285 --> 00:06:32,251
So when the dependencies are newer than the target
it returns the later of the dependencies.

63
00:06:32,605 --> 00:06:39,268
It could either return the latest
of the dependencies build times,

64
00:06:40,360 --> 00:06:46,491
but building a target will take time so it might be
a few seconds later than its dependencies were.

65
00:06:48,770 --> 00:06:54,880
Or, if its dependencies were last touched a long
time ago, but they're still newer than you are...

66
00:06:54,914 --> 00:07:02,182
We might get into like... Something
appears older than it actually is.

67
00:07:02,217 --> 00:07:07,222
So I think I should probably return time.now.

68
00:07:08,057 --> 00:07:11,908
Returns the ...

69
00:07:12,020 --> 00:07:16,948
In this context we've already
stubbed  mtime... [James thinks]

70
00:07:17,120 --> 00:07:19,531
TS: This reminds me of
something I was confused about,

71
00:07:19,554 --> 00:07:27,380
in the build self we get the
mtime of the possibly stale file.

72
00:07:27,380 --> 00:07:31,040
But you're talking about not
the mtime of that file at that point.

73
00:07:31,051 --> 00:07:35,622
But you're talking about almost the mtime
of that file after it's been regenerated.

74
00:07:35,908 --> 00:07:44,857
JC: Yes, because if you have a chain of dependencies.

75
00:07:47,840 --> 00:07:54,617
Say we have a file called 2 that
depends on 1 that depends on a.

76
00:07:54,720 --> 00:08:05,600
So if for some bizarre reason,
file 2 is newer than file a, but file 1 isn't.

77
00:08:06,090 --> 00:08:12,285
You will regenerate 1, which means you ought
to regenerate 2, but if 1 returns the mtime of a,

78
00:08:12,354 --> 00:08:15,108
then the 2nd will think it's up to date.

79
00:08:15,100 --> 00:08:21,348
So it really has to return the time right now
because it has to report to us down stream.

80
00:08:21,340 --> 00:08:25,222
"I was regenerated, I'm now newer than you".

81
00:08:25,268 --> 00:08:29,771
That's what I meant about
getting into ordering problems.

82
00:08:29,770 --> 00:08:33,588
So I want to say it returns the current time.

83
00:08:33,714 --> 00:08:38,560
I could stub Time.now but
I don't feel great about that.

84
00:08:38,560 --> 00:08:41,542
It's one of those global things,
if you stub it loads of things could blow up.

85
00:08:41,540 --> 00:08:44,331
We could try it and see if anything bad happens.

86
00:08:44,340 --> 00:08:45,817
Sometimes I'll indirect something.

87
00:08:45,810 --> 00:08:51,405
like make a method called current time that just
returns Time.now, and doesn't need testing really.

88
00:08:51,470 --> 00:08:55,885
And then I'll stub that, so it means the
rest of the system can use the real Time.now,

89
00:08:55,942 --> 00:08:59,188
but I've indirected the thing
the code is going to use.

90
00:08:59,280 --> 00:09:01,691
TS: Is the reason your
expecting it to return Time.now

91
00:09:01,702 --> 00:09:06,057
because that's what the mtime of
the newly generated file is going to be?

92
00:09:06,050 --> 00:09:11,200
JC: Yes. I could read the file system again to get that.

93
00:09:11,440 --> 00:09:17,691
TS: Is that better or worse than returning
the current time? I guess it's more expensive.

94
00:09:18,560 --> 00:09:23,280
JC: It would be more correct because all the times
you're using, are the times the file system has.

95
00:09:23,302 --> 00:09:30,171
If your ruby process is for some reason,
using a different locale from your OS,

96
00:09:30,457 --> 00:09:37,165
which may happen for some reason, then those times
may be in different time zones, they might conflict.

97
00:09:37,620 --> 00:09:42,342
mtime is really the correct thing. I think I'm
worrying about the fact that I've stubbed it up here.

98
00:09:42,365 --> 00:09:49,885
TS: Right, so you need mtime to return two
different values for the course of one test right?

99
00:09:50,148 --> 00:09:55,691
JC: Yes. We can try that. If it blows up, it blows up.

100
00:09:55,700 --> 00:10:02,434
By calling mtime twice with the same argument
makes it hard to distinguish the cause.

101
00:10:02,750 --> 00:10:09,325
I could say that it has to call some private
method to get its new time and assert on that.

102
00:10:09,360 --> 00:10:17,417
But... Let's try it this way and we'll
see if anything blows up in our faces.

103
00:10:18,125 --> 00:10:23,862
OK, so returns the new mtime of the file.

104
00:10:24,194 --> 00:10:31,428
Let's say that new mtime is, (I'm just going to
make that a double), I don't care what its value is.

105
00:10:33,177 --> 00:10:39,405
Although it does have to be a time because we're
stubbing this before the code gets run so...

106
00:10:42,457 --> 00:10:46,400
Why don't we say you can call this twice up here.

107
00:10:46,628 --> 00:10:53,108
[Silence]

108
00:10:53,554 --> 00:10:55,725
Let's say...

109
00:10:57,314 --> 00:11:04,445
Let's leave that called target_time and
then let's call this regeneration_time.

110
00:11:04,937 --> 00:11:14,434
And we'll say that regeneration_time
is target_time plus 10 minutes.

111
00:11:16,125 --> 00:11:18,068
That's somewhat arbitrary.

112
00:11:18,060 --> 00:11:22,800
TS: What's the syntax, where you've passed two
arguments into `and_return`. What does that mean?

113
00:11:22,857 --> 00:11:28,331
JC: That means, when you call this method
you will get each of these in sequence.

114
00:11:28,342 --> 00:11:32,697
The first time you call it you will get target time,
and the second time you will get regeneration time.

115
00:11:32,720 --> 00:11:33,920
TS: And that's exactly what you want?

116
00:11:33,954 --> 00:11:35,380
JC: Yes, that's great.

117
00:11:35,380 --> 00:11:46,342
I don't have to do that. I have to say "expect
target.build to equal the regeneration_time".

118
00:11:46,377 --> 00:11:50,034
That's what should be returned from this method.

119
00:11:50,125 --> 00:11:54,365
System will still be stubbed out because
it's stubbed out all the times. That's fine.

120
00:11:54,480 --> 00:11:58,182
Let's try running this.

121
00:11:58,742 --> 00:12:01,737
OK two failures.

122
00:12:01,730 --> 00:12:06,422
One in target spec and one in the integration tests.

123
00:12:06,420 --> 00:12:14,777
So it was expecting
regeneration_time and got echo high.

124
00:12:16,020 --> 00:12:23,074
That's because the end of our build self method...

125
00:12:23,088 --> 00:12:25,420
The last thing in that is
an each over the instructions,

126
00:12:25,456 --> 00:12:29,248
which each returns the thing it was called on.

127
00:12:29,302 --> 00:12:35,440
I think I want to leave that where it is.

128
00:12:35,737 --> 00:12:42,400
And maybe extract a thing...

129
00:12:42,948 --> 00:12:46,457
Yes let's extract a thing, forgetting the mtime.

130
00:12:46,742 --> 00:13:02,240
[Silence]

131
00:13:02,240 --> 00:13:06,560
File mtime... Yes.

132
00:13:09,097 --> 00:13:17,520
Up here I can do...

133
00:13:17,520 --> 00:13:21,440
target_mtime equals mtime.

134
00:13:21,920 --> 00:13:34,377
And then return_unless that
and any of those are greater than this.

135
00:13:34,370 --> 00:13:39,394
That cleans up that bit of code.

136
00:13:39,828 --> 00:13:47,440
And then up in our build method we can just
have that return mtime. That ought to be OK.

137
00:13:49,260 --> 00:13:58,937
Loads of things have blown up. I don't think
I've got the hang of unit testing. [Laughter]

138
00:14:04,820 --> 00:14:09,805
Now that we're calling mtime in the build method
in a code path that everything is going to hit,

139
00:14:09,908 --> 00:14:12,845
more tests have blown up.

140
00:14:13,010 --> 00:14:19,577
In some cases we're getting
mock expectation failures.

141
00:14:19,771 --> 00:14:28,777
There's a lot of logical failures here that aren't
just because the thing didn't return the right time.

142
00:14:28,770 --> 00:14:34,445
I will back that out and check that refactoring I did.

143
00:14:34,605 --> 00:14:39,268
Oh, I have actually broken something.
So I'm going to rewind all of this

144
00:14:42,902 --> 00:14:46,571
until we get back to what we wanted.

145
00:14:47,394 --> 00:14:49,954
OK let's make it work and then refactor it.

146
00:14:50,000 --> 00:14:59,497
So, if the file exists, pathname...

147
00:14:59,645 --> 00:15:02,937
Oh, well if you've built yourself
then your file should exist.

148
00:15:02,930 --> 00:15:06,137
TS: You hope.

149
00:15:06,350 --> 00:15:10,091
JC: Well if something failed you would have
got an exception and bailed out of this method.

150
00:15:10,148 --> 00:15:19,428
So let's assume that things worked and
just call file.mtime with the pathname.

151
00:15:21,074 --> 00:15:28,480
That's the only difference I've made, since the tests were in this state.

152
00:15:28,560 --> 00:15:35,474
We still get that loads of things explode.

153
00:15:36,010 --> 00:15:40,800
JC: Yes so those are the things
that don't exist when we call mtime.

154
00:15:40,925 --> 00:15:45,737
But we're not getting those mock expectations,
we still are getting some mock expectations.

155
00:15:45,794 --> 00:15:49,474
Oh, because there's an
assertion that it's called once.

156
00:15:49,640 --> 00:15:53,337
But those failures that we were
seeing before have mostly gone away.

157
00:15:53,360 --> 00:15:56,674
So either it's trying to call
mtime and it doesn't work.

158
00:15:56,754 --> 00:16:02,480
Or it's calling it twice when
it should be calling it once.

159
00:16:05,470 --> 00:16:15,737
What's the one where that said
it should be called once but it got twice?

160
00:16:15,931 --> 00:16:18,480
Line thirty-two.

161
00:16:21,268 --> 00:16:28,697
Maybe the once is implicit...
Check the mtime on its own file.

162
00:16:31,210 --> 00:16:35,862
TS: Can you relax that implicit constraint somehow?

163
00:16:35,965 --> 00:16:40,937
JC: Yeah... [James thinks]

164
00:16:40,930 --> 00:16:49,440
What is the context here? When you build it,
if the file exists it should call mtime twice.

165
00:16:50,400 --> 00:16:54,285
TS: First to decide whether to build it
and then to report to any downstream.

166
00:16:54,280 --> 00:16:57,634
JC: Exactly.

167
00:16:57,748 --> 00:17:01,337
We had 9 failures, and now we've got 8 failures.

168
00:17:01,330 --> 00:17:06,000
The other thing is that it's calling
mtime with loads of things that don't exist.

169
00:17:06,045 --> 00:17:10,788
So that is probably a thing that
needs stubbing out up here.

170
00:17:10,780 --> 00:17:14,548
So that's this thing I did up here to...

171
00:17:14,540 --> 00:17:16,948
Because I thought it would bypass
that code path, I wouldn't need to stub it,

172
00:17:16,960 --> 00:17:23,460
but now we're returning it in
all cases it still needs stubbing.

173
00:17:23,710 --> 00:17:30,480
And it ought to be sufficient to
return something of an acceptable type.

174
00:17:32,274 --> 00:17:33,862
JC: Now everything is green.