On 2/2/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > Jeremy Boynes wrote: > > On 2/2/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > >> Yes there is a disconnect here. Thanks for educating us on what a unit > >> test is, but somebody is going to have to explain to me how we test > >> Tuscany without using side files when the most of the SCA assembly spec > >> is about configuring and wiring components using SCDL side files. > >> > >> > > > > This is why we have a model - it allows us to separate how the > > configuration information is loaded from how the system is built. One > > set of tests can focus on parsing the XML files and checking that the > > appropriate model is generated; another can focus on converting that > > logical model into the runtime contexts; a third can focus on the > > operation of the contexts themselves. The model allows us to decompose > > this into more testable chunks. > > > So we'll need to test that we can work with SCDL, WSDL, XSD files. If > these are what you call "side files" (it actually depends on which side > of the Programming Model you are, in some scenarios these XML files are > going to be the primary artifacts with just a few Java files on the > side), we need to unit test the code that loads and parses these files. > These tests must represent an important part of our test suite, so > saying that unit tests should not use side files just does not fit at > all here.
What I said on the "testing strategy" thread http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200601.mbox/[EMAIL PROTECTED] was that there would be unit tests that tested loading resources like these. And as unit tests they should focus on that process, testing all the edge conditions involved in XML->model conversion. Another set of unit tests test the builders that generate the runtime, and others test the operation of the runtime contexts themselves. There are clear architectural boundaries here; if we can't test the components in isolation then we have introduced inappropriate coupling between them. > > > There is a lot to the specs that is not in the XML files, never mind > > the stuff that we want to add to the project that the spec does not > > cover. We need to manage the complexity to ensure that we get good > > coverage of all the components. > > > > > >> With respect to running Tomcat embedded or as you say even simpler > >> Jetty, I know that is is not a big thing. The only thing I'm saying is > >> that we need to focus and put priority on the main scenarios that we > >> want to support. As far as I know the main scenario that we want to > >> support at the moment is running Tuscany on top of an existing/regular > >> Tomcat installation, so we should focus our efforts on that scenario. If > >> we want to change direction in terms of architecture and instead focus > >> on running Tomcat or Jetty inside Tuscany, then fine , at some point we > >> can have an architecture discussion on this subject and determine > >> why/if/when we ever want to do that. > >> > > > > We're not talking about that here - we're talking about embedding > > Tomcat in JUnit so that we can quickly build/reconfigure the test > > environment to give better coverage when testing the Tuscany code. It > > would be a good idea though. > > > > > >> In the meantime I feel that running Jetty embedded in Tuscany with > >> made-up models constructed in memory from Java code is a little ... > >> disconnected... from our main goal, which is to run with SCDL files, > >> with Tuscany running on top of Tomcat. > >> > >> > > > > The goal in testing is coverage to make sure the code works as > > expected for all scenarios not just one. > > > Did I say that this was the only scenario we needed to test? I don't > think so. I said that we need to focus our attention on the main > scenarios, and I still don't think that running Tomcat embedded is going > to help us get there faster. > > -- I'm not sure what you're saying as we don't seem to be connecting on stuff like unit testing resource loaders and what Jim and I mean when we talk about embedding Tomcat. I think you are advocating a black box testing approach similar to what is in the acceptance test module where we boot a standalone Tomcat server and screen scrape the samples pages from it. I agree we need something like this. We are also advocating more whitebox testing with an emphasis on unit and integration testing done in the most efficient way possible using techniques such as mock objects and embedded containers. I hope you agree we need something like this as well. The two approaches complement each other so there is no reason to force one tack over the other. I am under the impression that you are working with Jack to get his changes in to make the acceptance module work again and I look forward to seeing it. In the meantime, Jim, Fuhwei and I have been working on more detailed unit tests which I hope are beneficial. There are plenty of other areas where we have way too few tests anyway. Let's focus on increasing our coverage and producing a quality server. -- Jeremy
