On Mon, 2007-01-01 at 10:02 -0800, Ask Bjørn Hansen wrote: > On Dec 31, 2006, at 8:15 AM, Guy Hulbert wrote: > > > I will write this up for the wiki ... unless someone already has > > (where?). I am still going to try to do some work on the test > > framework > > but that really depends on what the intent is there for which I will > > need to ask Ask, I guess. > > I'm not entirely sure what the question is, but ...
Well, you seem to have answered it ok :-). > > Ideally everything would be tested by automated tests. Matt or John The question is how large the universe is then. Presently the tests include '[EMAIL PROTECTED]' as data and return 502 when 200 is expected. At least on 0.3x it does. On 0.32 it passes, iirc. However, it behaves differently on my mail server, which has a functional qmail running than on my development box which runs exim (debian default). So I am suspicious that the tests are interacting with the system in some way. I tend to think in terms of "unit tests", "acceptance tests" although I realize that in practice there are many other ways of testing. I tend to think of the perl t/TEST_NAME.t tests as "unit" tests and I think of "unit" tests as testing individual function calls. >From what I see of qpsmptd there are several levels at which to test: 1. tests of the qpsmtpd framework 2. tests of individual plugins 3. tests of specific configurations I would look at 1 and 2 as unit tests but 3 as acceptance tests. End users will want to be able to run tests of type 3 but the framework is designed for plugins, many people will need to run tests of type 2 as well. There is, of course, some overlap between these 3 categories as well. What I generally find from perl modules is: 1. download 2. perl Makefile.pl 3. make test 4. make install and I can choose to let CPAN do this for me or not. It seems to me that qpsmtpd really wants an additional step: 1a. ./configure or 2a. make config and 3a. make configtest or perhaps a post-install step is better 5. qpconfig 6. qpconfig test Writing a plugin seems to be quite straightforward but doing it right seems somewhat challenging at the moment. > (IIRC) setup the initial testing framework and it should be possible > to make tests for all new code... I'm sure it is possible. I just don't know how yet. I will go back to working on it ... > > Happy new year everyone! :-) > > > - ask -- --gh
