Description
This issue was originally created at: 2008-05-30 01:36:05.
This issue was reported by: cournape.
cournape said at 2008-05-30 01:36:05
There is a lot of redundancy with hardcoded behavior in unit test. One easy refactoring would be the code used to check construction variables overriding: most unit tests rely on overriding the variable with a fake python command which filters most of its input. Instead of rewriting the code over and over, this could easily be put somehwere where everybody can use it.
cournape said at 2008-06-04 04:17:24
This was not really clear either according to the commen on last BugParty.
I think writing unit test for scons is more difficult than necessary. In particular, to test construction variables, fake commands are a nice way to do it, and scons uses it a lot. Since this is not abstracted, the easy solution is >to copy it. But this breaks for some cases:
- for my python extensions, some flags are read from some configuration: when the corresponding CC is set to a fake command, it has to parse those flags.
- On some platforms, the flags are not always empty: for pic code, it can be
-fPIC, or-KPIC, etc...To handle this now is a bit ackward, since every test has its own code. Having a ready to use one to handle all those cases in a nice way would be nice IMO. >Maybe not replacing existing ones, but at least use it for new code ? I have started doing this in my pyext branch for the pyext tool unit tests.
stevenknight said at 2008-06-04 06:31:55
Hi David--
Yes, that's what I understood this issue to refer to: centralizing creation of things like fake commands, to try to avoid cutting-and-pasting when creating tests.
Again, I'm not opposed to this if you want to spend time on it. If it genuinely makes writing tests easier, then great.
Part of why I haven't done this all that much is it always felt to me like a mock command for wrapping (e.g.) gcc starts to take on a life of its own, ending up having to understand and mimic a great deal of how gcc works when all you really need is to test one specific piece of it. If you don't mind taking that on, then fine.
The second thing to be aware of here is that the tests should still be self-contained and, ideally, not refer to any external files other than the modules in QMTest. This is because one part of the development workflow is to run the test against the unmodified baseline, and we don't want to use a file that comes from the baseline directory. (We can discuss this in more detail directly by mail.) So the preferred technique to centralize creation of fake commands would be to add a method to the TestSCons class that would create the fake command from in-line data, not to read it from disk.
HTH,
gregnoel said at 2008-06-05 15:33:02
Bug party triage.