House of Fusion
Search over 2,500 ColdFusion resources here
  
Home of the ColdFusion Community

Mailing Lists
Home /  Groups /  CFUnit

Order of Tests

  << Previous Post |  RSS |  Sort Oldest First |  Sort Latest First |  Subscribe to this Group Next >> 
Hi,
David Harris
09/23/07 10:37 P
OK.
David Harris
09/24/07 09:29 P
hi Andrew,
David Harris
09/26/07 07:04 P
TDD isn't used so you're not going to use it?
Neil Middleton
09/26/07 07:09 P
David,
Andrew Scott
09/26/07 07:47 P
Hi Andrew,
David Harris
09/26/07 07:56 P
David,
Andrew Scott
09/26/07 08:01 P
Top  |   Reply  |   Original Post  |   RSS Feed  |   Subscribe to this Group
Author:
David Harris
09/23/2007 10:37 PM

Hi, I am in the process of setting up some tests, and have a situation where I would like to use the results of one test in another test. EG: testOne checks I can create a new instance of ABCComponent in the database, and the "create" function returns the key for that instance testTwo attempts to delete the instance created in testOne Is it possible to control the order of the tests to this level? Thanks David

Top  |   Parent  |   Reply  |   Original Post  |   RSS Feed  |   Subscribe to this Group
Author:
Jerry Ela
09/24/2007 09:07 PM

No, each test starts with a clean slate.  Otherwise you would haveso many dependencies in the later tests that you wouldn't know if they really failed or if something that went wrong in an earrlier test was the problem David Harris wrote: ----- Excess quoted text cut - see Original Post for more -----

Top  |   Parent  |   Reply  |   Original Post  |   RSS Feed  |   Subscribe to this Group
Author:
David Harris
09/24/2007 09:29 PM

OK. I guess my logic would've been like this: testOne: variables.someValue = "[some value]" testTwo: if strcutKeyExists( variables , "someValue") - run the test else fail("required value wasn't made") Thanks for the help ----- Excess quoted text cut - see Original Post for more -----

Top  |   Parent  |   Reply  |   Original Post  |   RSS Feed  |   Subscribe to this Group
Author:
Jerry Ela
09/24/2007 09:58 PM

What you are trying to do is pretty common. There are lots of things you can only test after you have done a lot of things to set up an environment where things make sense.  But you have to do it all in one test case, making assertions along the way to make sure that everything is as it should be before you go to the next step. So you would write tests that look like this create a record run assertions on the create # of records before and after, primary key returned was as expected retrieve the record and run assertion on its values update the record retrieve and run assertions on its new values delete the record run assertions on # of records before after try to retrieve the record which should fail run assertions to be sure it did. The basic idea is that each test is a scenario that can test many assertions, and the test will fail and terminate as soon as one assertion fails. It is preferable that each test cover as little functionality as possible, but that is not alway possible.  Its also preferable to avoid modifying the db in your tests, but sometimes it is unavoidable. David Harris wrote: ----- Excess quoted text cut - see Original Post for more -----

Top  |   Parent  |   Reply  |   Original Post  |   RSS Feed  |   Subscribe to this Group
Author:
Andrew Scott
09/24/2007 10:23 PM

I am going to give some very helpful advice here. Read up on Test Driven Development, and remember that you are going to need to think differently as well. TDD, which is Test Driven Development is a way to write code in small chunks and get the tests to pass as you develop. Why is that important, is answered in a book called Test Driven Development by Kent Beck. The idea is that as you develop you are refactoring your code by test development to cover all your code with unit testing. This form of development is slower, and complex to get your head around if you are not used to it. But trust me you'll notice the benefits when it comes to maintenance and unforseen problems down the track. Another thing to remember is something called Mock objects, these can be very handy in a situation like you described because you can create a mock object and then test for its destruction as what you need to do. Also Mock objects are very good for DAO, TAO and such because you are writing tests that mimic what they should do and in these cases wouldn't write data back to the database if they are mock objects. Sorry to be a pain and throw this at you, but I think it is important to understand Test Driven Development first and how it works to benefit and appreciate it. Andrew Scott Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613  8676 4223 Mobile: 0404 998 273

Top  |   Parent  |   Reply  |   Original Post  |   RSS Feed  |   Subscribe to this Group
Author:
David Harris
09/26/2007 07:04 PM

hi Andrew, Thanks for the input, and as much as I would love to do "real" TDD, that method of developement isn't used where I work. Cheers, David ----- Excess quoted text cut - see Original Post for more -----

Top  |   Parent  |   Reply  |   Original Post  |   RSS Feed  |   Subscribe to this Group
Author:
Neil Middleton
09/26/2007 07:09 PM

TDD isn't used so you're not going to use it? Why?  What is honestly stopping you from using TDD? Neil ----- Excess quoted text cut - see Original Post for more -----

Top  |   Parent  |   Reply  |   Original Post  |   RSS Feed  |   Subscribe to this Group
Author:
David Harris
09/26/2007 07:18 PM

What can I say... I'm not planning to have a bit debate about developement processes in this forum. I am interested in using CFUnit in our developement environment, as I can see a use for it. To do TDD would require a major change to how we develope, which I can't make happen. Also, I was asking about the CFUnit testing framework, not a developement process... Cheers ----- Excess quoted text cut - see Original Post for more -----

Top  |   Parent  |   Reply  |   Original Post  |   RSS Feed  |   Subscribe to this Group
Author:
Andrew Scott
09/26/2007 07:47 PM

David, You are welcome, and I fully understand how you are positioned. I am in the same boat with an older project that I have been working on for the last 12 months, it isn't that I don't do TDD it is just that this Application is so huge I am only adopting the TDD for new features. BTW, I suggest that along with TDD (Test Driven Development) that one also look into Agile Methodologies as well. Combined they make for a better, faster development process. BTW if you think about it, most developers use a TDD approach anyway. Just that it is usually the test that are run last, then fix any problems. So can be hard to get to switch people around to test first, refactor, test etc. Andrew Scott Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613  8676 4223 Mobile: 0404 998 273 hi Andrew, Thanks for the input, and as much as I would love to do "real" TDD, that method of developement isn't used where I work. Cheers, David > I am going to give some very helpful advice here. > > Read up on Test Driven Development, and remember that you are going to need > to think differently as well. TDD, which is Test Driven Development is a way > to write code in small chunks and get the tests to pass as you develop. > > Why is that important, is answered in a book called Test Driven Development > by Kent Beck. The idea is that as you develop you are refactoring your code ----- Excess quoted text cut - see Original Post for more -----

Top  |   Parent  |   Reply  |   Original Post  |   RSS Feed  |   Subscribe to this Group
Author:
David Harris
09/26/2007 07:56 PM

Hi Andrew, Thanks for the comment. You are right that most developers do test as they develope, but there is a difference between testing as you go, and TDD :-) I'll have to put "real" TDD on my ever growing list of things to look in to! Cheers, David ----- Excess quoted text cut - see Original Post for more -----

Top  |   Parent  |   Reply  |   Original Post  |   RSS Feed  |   Subscribe to this Group
Author:
Andrew Scott
09/26/2007 08:01 PM

David, TDD, is test as you go:-) That's the misconception, but it is a different way of thinking as well. Hey, small steps big rewards and hopefully on the next project you do you can slowly introduce it. Andrew Scott Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613  8676 4223 Mobile: 0404 998 273 Hi Andrew, Thanks for the comment. You are right that most developers do test as they develope, but there is a difference between testing as you go, and TDD :-) I'll have to put "real" TDD on my ever growing list of things to look in to! Cheers, David


<< Previous Thread Today's Threads Next Thread >>

Search cfunit

May 24, 2013

<<   <   Today   >   >>
Su Mo Tu We Th Fr Sa
       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   

Designer, Developer and mobile workflow conference