I like "the naughties". Some guy had a campaign for this naming scheme pre-Y2K. It sets up a linguistic usage that is much like the previous eighties and nineties (i.e. Naughty-One, Naughty-Two...)
I somewhat agree with you but moving the sample data outside of the code to be tested could introduce side affects from test to test. For instance if you have 1 test that creates a file and the another that reads it, the order that the tests are run now matters. This is bad. This is the reason the setup method exists to explicitly set up test objects before running each test. Hard-coding the building of the object to be tested in the setup method is the only way to insure that your tests are operating on the same data. If you pull data from a file, even if you've made an agreement with yourself never to change that file, things have a way of breaking. When you're knee-deep in a test of a complex method the last thing you need is your sample data changing. Sometimes it can seem like a pain to set up a multi-level object (an object that contains multiple other objects), but in the end, I find this code is useful in *real* places in my code and this code can also help me understand how my object is put together.
Hilarious post! But on the serious tip, I believe that the most transparent way to set this up is to have a remote agent run on the client machine. ARCServe or Veritas both have products that can get the job done. Then, you can just teach the users to save everything in "My Documents". Backup each user's "My Documents" folder every night and call it a day. If they don't have it in that folder, you are not responsible. This method is much better than teaching them to save to their "H:\" or Home drive on the network ("Where's that H thing-a-ma-bob, again..."). Also, they can take their data with them if it is a laptop and when they leave it at work the next time the agent will run and back everything up.
Slashdot Mirror
And now for our first feat - "Unspecified Error"
I like "the naughties". Some guy had a campaign for this naming scheme pre-Y2K. It sets up a linguistic usage that is much like the previous eighties and nineties (i.e. Naughty-One, Naughty-Two...)
I somewhat agree with you but moving the sample data outside of the code to be tested could introduce side affects from test to test. For instance if you have 1 test that creates a file and the another that reads it, the order that the tests are run now matters. This is bad. This is the reason the setup method exists to explicitly set up test objects before running each test. Hard-coding the building of the object to be tested in the setup method is the only way to insure that your tests are operating on the same data. If you pull data from a file, even if you've made an agreement with yourself never to change that file, things have a way of breaking. When you're knee-deep in a test of a complex method the last thing you need is your sample data changing. Sometimes it can seem like a pain to set up a multi-level object (an object that contains multiple other objects), but in the end, I find this code is useful in *real* places in my code and this code can also help me understand how my object is put together.
Hilarious post! But on the serious tip, I believe that the most transparent way to set this up is to have a remote agent run on the client machine. ARCServe or Veritas both have products that can get the job done. Then, you can just teach the users to save everything in "My Documents". Backup each user's "My Documents" folder every night and call it a day. If they don't have it in that folder, you are not responsible. This method is much better than teaching them to save to their "H:\" or Home drive on the network ("Where's that H thing-a-ma-bob, again..."). Also, they can take their data with them if it is a laptop and when they leave it at work the next time the agent will run and back everything up.