Re: CFUnit Help ... assertEqualsBoolean?
Jeff Chastain <[EMAIL PROTECTED]> wrote: > testIsNullID(crTracker2._com.test.propertyTest): : expected:<...> >but was:<...> I have fixed this issue in the CVS version of CFUnit. This fix will be included in the next release. Thanks for bringing that to my attention ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225606 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
Re: CFUnit Help ... assertEqualsBoolean?
>>> testIsNullID(crTracker2._com.test.propertyTest): : expected:<...> but
>was:<...>
>
>Yes, this is copied verbatim and that is what really threw me. What in the
>world does that mean?
>
>Robert - I will try out some of your suggestions, but as Sean said, what is
>the '...' as a value?
>
>-- Jeff
The CFUnit outputs will try to trim down longer strings so that if you only see
the part that is different. For example, if you had these two strings:
expected = "Hello World, My name is Rob";
actual = "Hello World, My name is John";
Then the failure message might be something like
testSomthing(com.myTest): : expected:<... is Rob> but was:<... is John>
This is done to make massages about of very long strings, like XML, readable.
So when you see:
testSomthing(com.myTest): : expected:<...> but was:<...>
That means that the comparison logic said that the two variables where
different, but that when the logic tried to trim the strings down it could not
find the part that was different.
You are probably correct, it is probable the formatting of the two boolean
values are slightly different (1/0 vs yes/no vs true/false), so that the
comparison failed, but the formatting couldnât see the difference. Iâll
have to investigate this and correct it.
Note: The reason I left CFUnit dynamically typed was because ColdFusion is
dynamically typed. So therefore, in my opinion, so should its unit tests. So in
CFUnit all simple values are the same in assertEquals. A bit, integer, floating
number, and string are all the "simple" data type in CFML, so they are
evaluated the same way in the unit tests. Therefore, if you have a method that
returns type "numeric" you can still do this...
assertEquals("some message", myMethod(), "123");
Even though the 123 is in quotes - and therefore would be considered a string
in most strongly typed languages - ColdFusion still sees them both as simple
values, and can still consider them to be equal.
This does mean that when evaluating numbers (floating or integers) in CFUnit
you may need to wrap them in the numberFormat() function to insure they are
formatted the same. (However, when evaluating boolean values, I would suggest
using assertTrue/false).
In CFUnit, if you wanted to assert that a variable was a specific type, then
you would do one of these:
assertTrue("my message", IsBoolean( myvariable ) );
assertTrue("my message", IsNumeric( myvariable ) );
assertTrue("my message", IsDate( myvariable ) );
assertTrue("my message", IsObject( myvariable ) );
assertTrue("my message", IsXML( myvariable ) );
assertTrue("my message", IsArray( myvariable ) );
assertTrue("my message", IsStruct( myvariable ) );
assertTrue("my message", IsQuery( myvariable ) );
assertTrue("my message", IsBinary( myvariable ) );
ect... ect...
For example:
var expected = "123";
var myvariable = myCFC.getNumber();
assertTrue("The returned value is not a valid number", Is IsNumeric (
myvariable ) );
assertEquals("The returned value is not the expected value",
numberFormat(expected),
numberFormat(myvariable)
);
In this example, I would get a different (more informative) message if my
returned value was not numeric then I would if it was not the expected value.
(note: the assertEquals would still fail even if I did not assert the variables
type prior to calling it, because numberFormat would throw an error, but that
would be CFML thrown error, not a failure which I handle. Which you may or many
not prefer)
As mentioned before, CFCUnit has typed assertions. I personally prefer a single
assertion method myself, and feel this actually gives me more freedom. I guess
it comes down to personal preference.
~|
Logware (www.logware.us): a new and convenient web-based time tracking
application. Start tracking and documenting hours spent on a project or with a
client with Logware today. Try it for free with a 15 day trial account.
http://www.houseoffusion.com/banners/view.cfm?bannerid=67
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225421
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
RE: CFUnit Help ... assertEqualsBoolean?
Paul, Thanks for the info. As far as the application variables go, they are being passed into the object via the constructor (the init function), but it was the test case that was passing in the application variable via the constructor. This way, I don't have to duplicate the information in the Application.cfc file in every test case thus making changes more difficult down the road when a data source or mapping change. Thanks -- Jeff -Original Message- From: Paul Kenney [mailto:[EMAIL PROTECTED] Sent: Friday, November 25, 2005 11:58 PM To: CF-Talk Subject: Re: CFUnit Help ... assertEqualsBoolean? Jeff, cfcUnit and CFUnit are a bit different in how assertions are made. In CFUnit (like JUnit) there is a single function name "asserEquals". JUnit can take advantage of method overloading, so a single method name with different argument types will work. CFUnit takes the same approach and only has one assertEquals method that can accept any type for its expected and actual arguments, and it determines the type of assertion/comparison that needs to be done based on the determined type of the "expected" argument. cfcUnit is done differently. I have found that implying the type of test that needs to be done based on the types of the arguments gives up too much control and is harder to understand down the road. Instead, each type of assertion has its own method that is called explicitly by the test case methods. This is the default behavior for cfcUnit and does not require the use of any special base class. As far as testing for the presense of application variables within your test cases or making your objects under test aware of them, it is a bad practice (except in certain cases) and leads to untestable code. If you need these values to be available to your objects, it is best to pass them in explicitly via the constuctor or other method arguments. I hope this helps. Paul On 11/25/05, Jeff Chastain <[EMAIL PROTECTED]> wrote: > > Well, the reason I was going with the assertEqualsBoolean() was, how > can an equality test tell if a given string is a string or a boolean > type? I am getting the following failure ... > > testIsNullID(crTracker2._com.test.propertyTest): : > expected:<...> but was:<...> > > which I assumed had to do with the fact it was trying to compare > the string 'YES' with the boolean value 'true' and coming up short. > Now that I change the extends to grab the extra functions though, I am > still getting the error above. It is not the most descriptive as to > where the problem is . > > As a brief aside, I went and checked out CFCUnit to see if it was any > better documented. However, when setting up a test case there, it > does not appear that the execution of the test case includes the > Application.cfc file for the project. Am I missing something here or > am I doing something wrong by utilizing application level variables > (dsn, cfc mapping, etc.) in my test cases to pass to the object? > > Thanks > -- Jeff > > > > ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225316 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
Re: CFUnit Help ... assertEqualsBoolean?
Jeff, cfcUnit and CFUnit are a bit different in how assertions are made. In CFUnit (like JUnit) there is a single function name "asserEquals". JUnit can take advantage of method overloading, so a single method name with different argument types will work. CFUnit takes the same approach and only has one assertEquals method that can accept any type for its expected and actual arguments, and it determines the type of assertion/comparison that needs to be done based on the determined type of the "expected" argument. cfcUnit is done differently. I have found that implying the type of test that needs to be done based on the types of the arguments gives up too much control and is harder to understand down the road. Instead, each type of assertion has its own method that is called explicitly by the test case methods. This is the default behavior for cfcUnit and does not require the use of any special base class. As far as testing for the presense of application variables within your test cases or making your objects under test aware of them, it is a bad practice (except in certain cases) and leads to untestable code. If you need these values to be available to your objects, it is best to pass them in explicitly via the constuctor or other method arguments. I hope this helps. Paul On 11/25/05, Jeff Chastain <[EMAIL PROTECTED]> wrote: > > Well, the reason I was going with the assertEqualsBoolean() was, how can > an > equality test tell if a given string is a string or a boolean type? I am > getting the following failure ... > > testIsNullID(crTracker2._com.test.propertyTest): : expected:<...> > but was:<...> > > which I assumed had to do with the fact it was trying to compare the > string 'YES' with the boolean value 'true' and coming up short. Now that > I > change the extends to grab the extra functions though, I am still getting > the error above. It is not the most descriptive as to where the problem > is > . > > As a brief aside, I went and checked out CFCUnit to see if it was any > better > documented. However, when setting up a test case there, it does not > appear > that the execution of the test case includes the Application.cfc file for > the project. Am I missing something here or am I doing something wrong by > utilizing application level variables (dsn, cfc mapping, etc.) in my test > cases to pass to the object? > > Thanks > -- Jeff > > > > ~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225303 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
RE: CFUnit Help ... assertEqualsBoolean?
>> testIsNullID(crTracker2._com.test.propertyTest): : expected:<...> but was:<...> >> Do you really mean you get ... in the values? Yes, this is copied verbatim and that is what really threw me. What in the world does that mean? Robert - I will try out some of your suggestions, but as Sean said, what is the '...' as a value? -- Jeff ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225299 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
Re: CFUnit Help ... assertEqualsBoolean?
(The form messed up my last post, so let me try it agian via email, sorry for the double post) Jeff Chastain <[EMAIL PROTECTED]> wrote: >Well, the reason I was going with the assertEqualsBoolean() was, how can an >equality test tell if a given string is a string or a boolean type? I am >getting the following failure ... > > testIsNullID(crTracker2._com.test.propertyTest): : expected:<...> >but was:<...> > >... which I assumed had to do with the fact it was trying to compare the >string 'YES' with the boolean value 'true' and coming up short. Now that I >change the extends to grab the extra functions though, I am still getting >the error above. It is not the most descriptive as to where the problem is > The formatting of the variables might have that effect (I'll have to look at why the comparison logic seeing them as different, but the output format logic does not). If you think that is the case, you could handle it a few different ways. 1) Use number format (boolean values can also be bit... 0/1): 2) Use yes/no format: 3) Use assertEqualsBoolean form the extended TestCase class like you are doing, just make sure to extend TestCaseExtra, not just TestCase Or your fourth option - and I think this is probably what you will want to do: 4) use assertTrue: For example if you wanted to test that the "isSomthing()" method returns true: Or if it should return false: Hope that helps -- Rob Blackburn http://www.rbdev.net ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225295 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
Re: CFUnit Help ... assertEqualsBoolean?
>Well, the reason I was going with the assertEqualsBoolean() was, how can an >equality test tell if a given string is a string or a boolean type? I am >getting the following failure ... > > testIsNullID(crTracker2._com.test.propertyTest): : expected:<...> >but was:<...> > >... which I assumed had to do with the fact it was trying to compare the >string 'YES' with the boolean value 'true' and coming up short. Now that I >change the extends to grab the extra functions though, I am still getting >the error above. It is not the most descriptive as to where the problem is > The formatting of the variables might have that effect (Iâll have to look at why the comparison logic seeing them as different, but the output format logic does not). If you think that is the case, you could handle it a few different ways. 1) Use number format (boolean values can also be bit... 0/1): 2) Use yes/no format: 3) Use assertEqualsBoolean form the extended TestCase class like you are doing, just make sure to extend TestCaseExtra, not just TestCase Or your fourth option - and I think this is probably what you will want to do: 4) use assertTrue: For example if you wanted to test that the "isSomthing()" method returns true: Or if it should return false: Hope that helps ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225294 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
Re: CFUnit Help ... assertEqualsBoolean?
On 11/25/05, Jeff Chastain <[EMAIL PROTECTED]> wrote: > Well, the reason I was going with the assertEqualsBoolean() was, how can an > equality test tell if a given string is a string or a boolean type? I am > getting the following failure ... > > testIsNullID(crTracker2._com.test.propertyTest): : expected:<...> > but was:<...> Do you really mean you get ... in the values? -- Sean A Corfield -- http://corfield.org/ Got frameworks? "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225291 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
RE: CFUnit Help ... assertEqualsBoolean?
Well, the reason I was going with the assertEqualsBoolean() was, how can an equality test tell if a given string is a string or a boolean type? I am getting the following failure ... testIsNullID(crTracker2._com.test.propertyTest): : expected:<...> but was:<...> which I assumed had to do with the fact it was trying to compare the string 'YES' with the boolean value 'true' and coming up short. Now that I change the extends to grab the extra functions though, I am still getting the error above. It is not the most descriptive as to where the problem is . As a brief aside, I went and checked out CFCUnit to see if it was any better documented. However, when setting up a test case there, it does not appear that the execution of the test case includes the Application.cfc file for the project. Am I missing something here or am I doing something wrong by utilizing application level variables (dsn, cfc mapping, etc.) in my test cases to pass to the object? Thanks -- Jeff ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225290 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
Re: CFUnit Help ... assertEqualsBoolean?
On 11/25/05, Jeff Chastain <[EMAIL PROTECTED]> wrote: > I am needing a bit of help with CFUnit from those more experienced. I have a > cfc function that returns a boolean. Looking through the CFUnit code, I > found the 'assertEqualsBoolean' which I thought might be an equality test for > 2 boolean values. I have checked that my function is in fact returning true > (actually 'YES'), but I am getting an error on my assertion from CFUnit. The typed asserts are only in TestCaseExtra, not in the basic TestCase CFC. If you change your test component to extends="net.sourceforget.cfunit.framework.TestCaseExtra" then the method will be available. TestCaseExtra extends TestCase and adds typed asserts. Or you could just assertEquals() in your code instead of assertEqualsBoolean(). -- Sean A Corfield -- http://corfield.org/ Got frameworks? "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225273 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
