Lets use mock when possible but certainly Cactus is fine for when mock won't suffice. Also, I suggest we focus on testing tomahawk for now since we basically have a pretty decent test suite for the implementation (the TCK tests.)
sean On 9/22/05, Bill Dudney <[EMAIL PROTECTED]> wrote: > Hi All, > > I like the idea of mock objects that will give us easier to test > components. > > In particular though the inputDate component (tag, renderer and > UIComponent subclass) has many bugs filed against it (#233 is a good > one to use as a spring board to fix the others though) and some of > them would be very hard to test with a mock renderkit. > > I've attached a JUnit test that uses mocks and a cactus test that > runs in container that test the same thing for people to compare. > This is part of the testing I'm doing for the inputDate stuff and bug > #233. > > TTFN, > > -bd- > > > > On Sep 22, 2005, at 9:13 AM, Mike Kienenberger wrote: > > > 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 > >>>> > >>>> > >>> > >>> > >>> > >> > > > > > > >
