more things to do

1 files changed, 30 insertions, 4 deletions

diff --git a/test/TODO b/test/TODO
index 06509c5..096f250 100644
--- a/test/TODO
+++ b/test/TODO
@@ -1,23 +1,45 @@
+#
+# Things to do for testing
+#
+
 * get current tests running
   * this will mean replacing disktest with something
     (like fio?)
 
-* ensure user is root?
+  PASS -- no need to spend time getting disktest working
+  when (1) it's hard to find, and (2) it's going to be
+  replaced anyway.
+
+* ensure user is root? -- easy to do
 
 * have tests create their own target using targetcli and
-  a file?
+  a file? -- this would be much better, but would pull
+  in a requirement for targetcli-fb and friends, plus we
+  would still need a place for a decent-sized (1G?) file.
 
 * have tests do discovery themselves, instead of requiring
   that to be done already. Either way, we may still need
   to know the IQN of our target and the host where it lives.
 
+  PASS -- we still would have to know two things (IQN and
+  IP:Port). See next item.
+
+* Have tests figure out the device path, so it doesn't have
+  to be passed in. Passing it in requires the called to
+  login to the remote iscsi target and look at the path
+  in /dev/disk/by-id (for example). If we created the
+  disk, we might have a better chance of guessing its name?
+
 * Augment tests
-  * framework for adding new tests and test types,e.g.:
+  Right now, the test is a long-ass regression test. Very
+  repetitive and time-consuming. But we also have need of
+  regular unit tests, e.g. for functionality, where a new
+  test could be added each time we find a bug? New tests
+  could include things like:
     - multipathing
     - using interface files or not
     - discovery, with and without authentication
     - session creation, w/ & w/o auth
-    - etc
 
 * Gather actual regression data!
   - Since we are testing all of these combinations, why not
@@ -40,3 +62,7 @@
 
 * Leave the regression test around, for now? It doesn't run,
   so maybe it should just be removed?
+
+* Add in option to specify which subtests (of 16) are run
+  for each test case. Would make it much faster for testing
+  and go/no-go testing?