> I often fix the test case before I fix the code, to remind me to fix the > code. :)
Yes I think it's a good idea to add failing tests that are known to be good, but not done yet. I think we could annotate them as follows: testing "name" "command" "result" "infile" "stdin" # good test known-fail "name" "command" "result" "infile" "stdin" # test that fails, but is valuable If we had a continuous build, we could keep it green, preventing regressions of the tests that do actually pass. And then there could be a mode of the test harness that runs the known-fail tests. If they pass, the function can be changed to "testing". Although there is the complication that they could pass in one environment but not another. > (I don't always check those in though, because "git diff" showing me a > comment or hunk of code is an easy way of keeping track of todo items.) How about just working on a branch "rob-todo" ? And then "git diff master.." instead. And then 'git pull' becomes 'git pull' and 'git merge master'. I noticed you just switched from hg, and so did I. I liked hg a lot better because the commands actually make sense, but git's branching is why it's popular. It really is pretty killer and lets me work on the test harness while you are reviewing the expr code, etc. The way I think of it is that hg is for single person projects (most of mine were) while git is for collaboration... and that explains why git is popular despite being incomprehensible. I find it really helps to put the git branch name in your bash prompt (if you want a pointer let me know.) Andy _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
