| Issue 59: | Assertion Improvements | |
| 1 person starred this issue and may be notified of changes. | Back to list |
I think we need to kick some assertion ass. here's what i had in mind, to start: assertEqualsQuery assertEqualsStruct assertEqualsArray the big thing here will be in making them do something meaningful, which is to show exactly what is different when the assertions fail. it could continue to use the current method for evaluating equality because it works nicely. But the next step is that, when the assertion fails, it should run additional functionality that will put a nice, easy to understand structure of the differences between the two objects into the debug struct. So if you're working with a test that does assertEqualsQuery(q1,q2), and it fails, you run the test and you hit "b" in the eclipse plugin and there in the debug struct is a cfdump of exactly what is different. Currently, what you get is a string representation of the difference, and in anything but the most braindead simple objects, this is virtually unreadable. The key here is to make the differences meaningful so that they can be acted on.
Jan 22, 2009
Project Member
#2
virtix
Feb 28, 2009
Perhaps this improvement would solve cases like this too:
This test
<cffunction name = "test_Dates"
access = "public"
returntype = "void">
<cfset var vExpected = CreateDateTime(2008,2,5,0,0,0)>
<cfset var qTest = QueryNew("xGroup1","Date")>
<cfset QueryAddRow(qTest, 1)>
<cfset QuerySetCell(qTest, "xGroup1", vExpected, 1)>
<cfset assertEquals(vExpected, qTest.xGroup1[1])>
</cffunction>
fails with this message:
...AssertionFailedError: ::[2008-02-05] NOT EQUAL TO [{ts '2008-02-05 00:00:00'}]
Feb 28, 2009
Good point!
Jun 30, 2010
older/outdated issues. archive in google docs. These are either Fixed, deprecated, or invalid moving to Jira
Status:
Fixed
|