I posted this awhile back on the user list, but what about the possibility of a "testing" renderkit? The "encoding" would write values to a Map, and the "decoding" would read them from a Map. As was pointed out before, it might not work with AJAX, but it'd certainly simplify a great deal of the testing. You'd still need some kind of html-testing (maybe cactus) at some point to test the html render kit, but ideally, each render kit would be tested independently of everything else anyway.
On 9/22/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > A few comments/questions on Bill's proposal... > > The first is, do we want to go with Cactus, Cargo and Ant for this? I > don't have a problem with this although we've talked off and on about > using Maven for this at some point. Since our biggest Maven guru > (James Mitchell) is busy with some other stuff right now I say lets > stick with what we know. > > One thing I think we should do is check out what Craig and the gang > are up to in Shale. They have all of these mock objects, etc that > they are using to test Shale. Lets make sure they haven't figured out > something already that we could use or easily adapt for our use. > > There are a lot of extra dependencies but they are only for the build, > not the actual usage of myfaces or tomahawk so I don't think that's > too big of a deal. One option is a separate target for downloading > the dependencies associated with the tests, but that might be a bit > much. That does mean, however, that in order to build from the source > you are required to supply your own local jars or use > download-dependencies and download some jars that you might not have > otherwise needed. > > @Bill, > > You asked about breaking things with this new build. Here is a good > rule of thumb for you to verify this. Do an SVN checkout of > myfaces-current and then do a unit-test-all from current/build. Then > do clean-all from the same dir (to reset things). Then go to each > subproject and build indepedently (but in a logcial order b/c that is > still required). So api/build unit-test, share/build unit-test, > impl/build unit-test, etc. Also you should probably do the same for > dist-all at the top level and then dist at each of the subproject > levels. Just to make sure that "one build to rule them all" still > applies. > > I will try the patch shortly when I get some much needed free time. > > sean > > > > On 9/22/05, Enrique Medina <[EMAIL PROTECTED]> wrote: > > Yes, a good tutorial on the wiki would be great! > > > > 2005/9/22, Martin Marinschek <[EMAIL PROTECTED]>: > > > I believe that there is no problem for us in adding any dependencies > > > as long as they are ASL licensed... > > > > > > If you would write up some stuff on how to get started with testing, > > > it would be great - I hope we can then get the other developers > > > (including me) to write those tests as well. > > > > > > regards, > > > > > > Martin > > > > > > On 9/22/05, Jesse Alexander (KBSA 21) > > <[EMAIL PROTECTED]> wrote: > > > > -----Original Message----- > > > > With the TCK behind us (thanks again to all who worked so hard on > > > > that) I figured it was a good time to work on getting cactus tests in > > > > place. My thinking behind Cactus is that we need to have the ability > > > > to do in container testing because some of the mock stuff is just too > > > > tedious. As background info I've been working on bug # 233 (empty > > > > date for inputCalendar) and its just too complex to test all the > > > > cases with mocks because of the amount of code that must be written > > > > to setup the mock env. > > > > -----/Original Message----- > > > > Good to hear that. Developing my own components I also have the problems > > > > > > > > of testing. If we all join forces and know how on that, we can come up > > > > with a sample of testing components... > > > > > > > > -----Original Message----- > > > > So I set out to get a cactus test env that I could execute container > > > > side tests in and I've gotten a fair way there. > > > > -----/Original Message----- > > > > good to hear > > > > > > > > -----Original Message----- > > > > The Good: > > > > 1) Cactus gives us an alternative means to test (in the container) > > > > 2) Cargo integration will be a great way to build tests that > > > > automatically invoke the example code on a wide range of containers > > > > with each release. This will help us avoid problems with the various > > > > containers because of a lack of testing. > > > > -----/Original Message----- > > > > Cool. Maybe I should revive my ant-task for the Yourkit-profiler? > > > > Right now I have a web-app (done with JSF) and a servlet (for use > > > > with JMeter and similar) to control the Yourkit Profiler from distance. > > > > For an old version I once had also an ant-task... but I seem to have > > > > lost that source... > > > > > > > > -----Original Message----- > > > > The Bad: > > > > 1) more dependencies > > > > 2) we don't seem to have a ground swell of support for testing so > > > > this all might be for nothing > > > > -----/Original Message----- > > > > Dependencies are only for build and testing? Is that so bad? > > > > > > > > -----Original Message----- > > > > What are you thoughts? Since introduction of JUnit I've not seen any > > > > additional tests being added to the mix. Its a huge task to get test > > > > coverage but I think its worth it, we will significantly reduce the > > > > uncertainty in doing a release if we can get a good set of tests in > > > > place. > > > > -----/Original Message----- > > > > JUnit is on e part of the game. But with presentation layer stuff the > > > > incontainer-testing is a must. The applications that depend on Myfaces > > > > may not need it (maybe they also need it...), but the confidence the > > > > incontainer test can give is important for future changes... > > > > > > > > -----Original Message----- > > > > I'm working on getting some more JUnit tests in place and would love > > > > to write up what is required if that would help others get started. > > > > -----/Original Message----- > > > > Way cool. > > > > > > > > regards > > > > Alexander > > > > > > > > > > > > > -- > > > > > > http://www.irian.at > > > Your JSF powerhouse - > > > JSF Trainings in English and German > > > > > > > >
