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-
HtmlDateRenderCactus.java
Description: Binary data
HtmlDateRendererTest.java
Description: Binary data
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? Idon'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 thatthey are using to test Shale. Lets make sure they haven't figured outsomething 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 bitmuch. That does mean, however, that in order to build from the sourceyou 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 dependenciesas 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 onthat) 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 tootedious. As background info I've been working on bug # 233 (empty date for inputCalendar) and its just too complex to test all thecases with mocks because of the amount of code that must be writtento setup the mock env. -----/Original Message-----Good to hear that. Developing my own components I also have the problemsof testing. If we all join forces and know how on that, we can come upwith a sample of testing components... -----Original Message-----So I set out to get a cactus test env that I could execute containerside 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 thatautomatically invoke the example code on a wide range of containers with each release. This will help us avoid problems with the variouscontainers 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 usewith 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 havelost 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 inplace. -----/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 theincontainer 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
