Hi Michael, Our design actually uses session bean facade and I agree that in a way we're bypassing the session bean facade to actually create the data related to the use case we are testing. We do this by sampling data in the worksheet and then saving it as CSV file. After that, we upload it to the database before running the test servlet that invokes the session bean's method.
The reason for this awkward approach is because most testing framework provides a setup method where we can install the data that we need in order to capture the necessary status of the related components of the scenario we are testing for functionality. But this seems to be impractical if we set all the data programatically if we have a huge dataset. For example, some business applications consist of a cycle, let's say accounting software. We set the beginning balances, create journals, post these journals, open/close periods, etc. At the end of the year you execute year-end closing. Now, year-end closing module is the end of the accounting cycle and it assumes that most of the module are already executed and correct data are already in place. What I'm driving at is, in order to test year-end closing module funtionalities, you need to capture the state of several entities, _as if_ the prerequisite modules are already executed and necessary data are already in place, in order to properly test it. In our case, it's not impossible to create a dataset composed of hundreds of rows spanning several tables. If we're to set these data using most of testing framework's approach, we have to generate hundred lines of code just for setting of data. Or is there a more convenient way specifically in Cactus? The problem with the upload-approach is that we couldn't do a one upload and one run, much like a test suite, since we need to upload different set of data for each use case or scenario. It's somehow convenient than programmatic setting of data but I'm still looking for an elegant way of doing this. Thanks, John --- Michael Mattox <[EMAIL PROTECTED]> wrote: > Is your design such that the only way to put data in > the database is by > using the EJB service (session bean facade) layer? > If this is true then > I like #3. If you do a data upload then you're > bypassing the service > layer, and then later testing your service layer > against the data that > it didn't create. I think you can better test your > service layer if you > use it to populate your data. If not there is the > possibility for > descrepencies. > > Now if you're design allows another layer to access > the database > directly (a JSP, servlet, or another application for > example), then the > data upload approach makes more sense. However in > this case I'd > consider redesigning to enforce all database calls > to go through the > service layer. > > Michael > > -----Original Message----- > From: John Denver [mailto:[EMAIL PROTECTED]] > Sent: Friday, August 09, 2002 9:32 AM > To: Cactus Users List > Subject: Question on Functional Testing in Cactus > > > The problem that we're having with our EJB > functional testing is that you need to *set* the > status of the entity beans before a full use case > can > be tested against a session bean. > > Presently, everytime we test a use case or set of > use cases, we upload related data to the database so > that we can capture the state of the related entity > beans before running the session bean(s) of the use > case(s). This means to say that whenever we do a > regression testing and we have 50 use cases, we need > to upload different sets of data approx 50 times and > run the session beans in between uploads. Not very > smooth. > > Second alternative solution I can think of is to > create a god dataset so that there will only have > one > upload and one run. But the problem is its difficult > and time consuming to design a god data that is > *valid* to all use case and future use cases for > future features. > > Third alternative solution I can think of is to > set > the individual data programatically within the test > script. These solutions in my opinion is equally > time consuming if we > need to set several rows spanning several tables > with several fields > that's why we preferred data upload. > > I believe that this is not only applicable to EJB > but to all functional testing that uses object > states. > How do you guys do this and what's the best way to > do > this, such that ideally we can test all the use > cases > in just one run (and probably only one upload) > similar > to test suite of unit testing. My understanding is > Cactus focus on Functional *Unit* Testing and not > the > standard Functional Testing. If my assumption is > incorrect, how do you effectively set the status of > the entity beans/units that composed of large data > set > so that a full use case can be simulated and tested? > > Thanks in advance. > > John > > __________________________________________________ > Do You Yahoo!? > HotJobs - Search Thousands of New Jobs > http://www.hotjobs.com > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
