Hi Jeanne - I moved your post as I think it's a topic that deserves its own thread.
You're already ahead of me in your use of a testing framework for SML. I just wrote ad hoc boolean functions to test specific functions e.g. to test if rev_string() actually reverses a given string:
I haven't used ML since the course, but it seems sensible to use a unit testing library - even a simple one - if one is available.
The printing thing is a new one on me - I just put my test results in a list then inspected the list. I know I/O is problematic in pure functional languages because it has side effects - each time you call the read/print operation you leave the system in a different state - but I though most languages had a way around this by encapsulating the side effects with monads or something. Maybe somebody else knows more about how to manage this kind of thing in SML?
As for learning Emacs, respect! I need to find time to try it again, as it seems all the Cool Kids are using Emacs these days...
Looks good. If I did it again I'd definitely want to investigate a unit testing framework. I did take the time to use a proper framework for the next two languages in the course (Racket and Ruby), but for SML I took a similar approach to Chris. I did try to make the tests a little more "expressive" by assigning a comparison to a variable with a relevant name (helpful because when I ran the file these are printed along with the True/False), but it was still a matter of scanning the output for any Falses.
As a quick example, here's one of my tests from the first assignment.
Yes, I used RackUnit for Racket testing, which was very useful (I vaguely recall that Matt may have recommended it in the course forum - if so, thanks!), and RSpec for Ruby, but we didn't do all that much with Ruby, so I didn't really make much use of RSpec either.
Chris: The problem isn't printing from SML. That worked fine. The problem is keeping track of state to print out at the end if any of the tests failed. The author of the suite uses Python for that and I used a shell script. I don't see myself using emacs much after the class. It's fine though. Just because I'm so much faster in vi and I don't see the need to invest time to become THAT proficient in emacs. But I'm fast enough for the purposes of the class in one day. I expect I'll get better in the next few weeks too.
Matthew: That's what the professor's sample tests look like. I rely too much on JUnit in my real job (and coderanch development for that matter) that I want to be able to push one button and know if I'm good. I don't have the desire to go back to scanning output to see if there are any falses printed.