1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
|
Feature oriented Revision history for Test-DBIC-ExpectedQueries
===============================================================
2.002 -- 2020-05-09 13:55:33 UTC
* Fix issue #6, sub-selects identifis table as "select".
New option "report_subselect_tables" to try to find the first table
actually selected from.
2.001 -- 2019-08-12 17:39:31 UTC
* Support a test description, and report the test correctly.
* Fix the stack trace so it's less spammy (filter out more common
infrastructure modules), and more readable.
2.000 -- 2019-07-17 21:14:39 UTC
* BREAKING CHANGE -- This release includes a bug fix to the
library. It now tests queries more comprehensively (i.e. all
queries).
You may find your tests now breaking when previously they didn't. If
this happens, you always had inaccurate tests but
Test::DBIC::ExpectedQueries didn't flag this up correctly.
This is the fault of this library, not your code. Sorry about that!
It is however your problem, and now you need to fix your tests.
If you need to make your tests pass immediately, pin the version to
pre 2.000, e.g. if you have a "cpanfile" in your project:
requires "Test::DBIC::ExpectedQueries", "< 2.0";
The fix you need to make is that the library will now report queries
that were supposed to run n times, but didn't run at all. Let's say
you have the check:
{ book_lender => { select => 1 } }
You might see failures for queries that were supposed to run n times, but
didn't run at all, e.g.
Expected '1' inserts for table 'book_lender', got '0
Whether this is a problem or not depends on the situation. Either
you're happy that you're not making any redundant queries because
the information is cached or prefetched. Or this indicates a
problem, because something that you thought happened isn't.
In the former case, a useful fix is to either remove the line or to
relax the test:
{ book_lender => { select => "<= 1" } }
1.011 -- 2015-11-05 15:18:09 UTC
* Bug fix: Avoid wantarray being masked inside try-catch block
1.010 -- 2015-09-23 22:16:24 UTC
* Bug fix: stack trace ignored classes
1.009 -- 2015-09-20 21:34:08 UTC
* Table level option "stack_trace" to show a strack trace for each SQL
query that fails.
1.008 -- 2015-04-27 14:49:49 UTC
* Replace Attribute::Exporter with Exporter::Tiny, since
Attribute::Exporter gone dun weird.
1.007 -- 2015-04-27 13:25:09 UTC
* Fixed prereq on Attribute::Exporter
1.006 -- 2015-02-23 09:14:44 UTC
* Fix #1 - Dereference hash for calling 'keys'
- patch by Syohei YOSHIDA (syohex)
1.005 -- 2015-02-22 17:58:28 UTC
* More POD improvements
1.004 -- 2015-02-20 17:30:45 UTC
* Default ->test() to an empty hashref
* Reset collected stats when calling ->test() properly!
1.003 -- 2015-02-20 16:48:11 UTC
* Reset collected stats when calling ->test().
1.002 -- 2015-02-20 14:34:10 UTC
* Even more better POD docs.
1.001 -- 2015-02-20 13:51:38 UTC
* POD
1.000 -- 2015-02-19 20:51:12 UTC
* First release
|
