Hi there, While I was working on the testing matrix, I've played with tests, and this gave some thoughts, even worries... Here there are, not very structure, I'm sorry, they come as they are :)
My main worry is how the number of test can grow (number of columns in the matrix), while the number of target could stay low (number of rows). I mean, how many board files will we have ? Do people have as many boards as PICs ? About the number of columns, while generating the matrix, I thought it would be better to check what if the feature used in the tests. This means looking into the code, search for "include" statement, and report them: columns don't show tests, but the lib they use. One of the big advantages of tests is to avoid code duplication: the test logic remains the same, while the chip configuration always change. The drawback is you can't get one single file and compile it. Samples can do this, are not so good (even bad), because of code duplication. I can remember Joep was suggesting to have three files: one for the test logic itself, one for the target chip configuration, one for the board configuration (correct me if I'm wrong). While there might not be a lot of different board files (I guess), there can be a lot of target conf files. At least, because some people here seem to have a *LOT* of PICs, on which they can test a blink samples: this doesn't require a board, but a different conf for each target. This blink samples are generated by our famous Rob. My question is: could it be possible to generate samples ? I mean: you take a test code (just the test logic) + a target conf = a ready-to-compile sample. This means we could migrate samples into test logic only code (potentially the same as tests), and generate them for a lot of different PIC. I don't know what should gone into the configuration file, maybe that's not feasible, because it's too variable, I just don't know. Rob, how do you do this with your blink samples ? How did you define the target configuration ? If we take only the configuration part of your blink samples (clock, osc, wdt, ....), would it make sense ? If so, could it be possible to generate only the config part ? In other words, we have plenty of blink samples, because there are generated. Could we have the same for all samples ? (provided they support the tested feature, of course). We would only have to write the test logic, in the "test" map, then run the magical script to generate a lot, a lot of samples ! Wow... (I hope someone here can understand what I mean...) Seb -- Sébastien LELONG http://www.sirloon.net http://sirbot.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jallib?hl=en -~----------~----~----~----~------~----~------~--~---
