DELTA 114 119 258
SVN  ‚»3º # €º: Test Plan}
\author{Andrew La Motte-Mitchell}
\date{\svnToday}

\newcounter{test_num}
\setcounter{test_num}{1}
\newcommand{\test}[3]{\noindent \textbf{Test Number: } \arabic{test_num} \stepcounter{test_num}\\
				\emph{Purpose: } #1 \\
				\emph{Description of Test: } #2\\
				\emph{Pass Criteria: } #3\\}

%\newcommand{\test}[3]{ 
%\begin{tabular}{ll}
%\textbf{Test Number } & \arabic{test_num} \stepcounter{test_num} \\
%\textbf{Purpose} & #1\\
%\textbf{Description of Test} & #2\\
%\textbf{Pass Criteria} \\
%\end{tabular}}

\begin{document}
\svnInfo $Id$ 
\maketitle


\section{Module Testing Overview}
In this document, we will detail the test-plan for the \textsc{Synchronizer} module, whose design is specified in the document \emph{Cue: Personal Device Synchronizer}. This module is responsible for the manual and automatic synchronization of files between a device (such as a PDA or iPod) and a computer. We will provide a number of general acceptance tests, to verify that all required functionality has been achieved, and then we will give more detailed white-box tests that will  thoroughly exercise the module. Because our architecture is highly modular, the \textsc{Synchronizer} component can be tested without the need for complex stubbing.  In following sections, we will describe in greater detail the elements that must be stubbed, and the testing framework in general. 
 
\section{Test Automation Framework}
This module lends itself well to a data driven framework. We will prepare various dummy files and directories to simulate the contents of the computer database and the personal device. Then we will exercise our code on these data, and compare the output to our pre-prepared, expected output. No test case will be able to overwrite or modify input files. Instead, their output will be stored elsewhere, so each test-case operates on carefully manufactured data.  This will ensure an isolated testing environment, which will allow us to effectively determine if each aspect of the \textsc{Synchronizer} is performing as desired. 

Each test case will compare the output given by our program to the expected output.  If they are identical, the given test passes.  Otherwise, an error will be reported that will not affect the rest of the test suite.  At the end of the testing process, the user will receive a brief message announcing which test cases failed. A detailed test-report will be saved to file so that the user can decide to investigate the failed test-cases at her leisure.  

We will write a small program to run this test suite.  This program will have access to the private methods, so each can be tested individually (this can be done in the implementer's favorite way).  Given the pre-prepared data, the user simply needs to execute this program, and each test case will run.  As mentioned above, any failures will be reported in a brief summary and in detail.  The detailed version should give the following information:
\begin{itemize}
	\item Test case number,
	\item Input given,
	\item Expected output, and 
	\item Actual output
	\begin{itemize}
		\item For large amounts of output, the test program will save the expected and actual output to file, and let the user examine the differences using a diff tool. 
	\end{itemize}
\end{itemize}

\section{Elements to be Stubbed}
There are basically only two components that the \textsc{Synchronizer} must interact with: the database and a generic device.  We do not need to create a stub for each specific device that will be supported, since this functionality is handled in other modules\footnote{As detailed in the document \emph{Cue: Personal Device Synchronizer}, the synchronizer is implemented at a higher level of abstraction than the individual device drivers.}.  Instead, we must create a stub that simulates the behavior of any generic device. Now we will specify exactly what each stub must be able to do.
\begin{enumerate}
	\item[] The Database will provide:
	\begin{itemize}
		\item the ID for this computer - the number devices will use to determine acquaintance. 
		\item a list of device model numbers that are supported (can be arbitrary, as long as one is the number of the generic device we are stubbing). 
		\item a list of known devices that can be read and written to,  We will need two copies available, one that is empty and one that includes the ID of the stubbed device.
		\item a change log, for the stubbed generic device, that can be either empty, or have a manufactured list of file names. 
		\item the ability to \emph{access} files from the database. What we'll really do is prepare a few dummy files that we can return.  No actual database is necessary.
		\item the ability to write files to the directory that stores dummy files, simulating a writable database. 
	\end{itemize}
	
	\item[] The device will provide:
	\begin{itemize}
		\item the ID for this device - the number the computer will use to determine acquaintance. 
		\item a list of known computers that can be read and written to. We will need two copies available, one that is empty, and one that includes the ID of the stubbed database. 
		\item a change log, for the stubbed computer database, that can be empty, or have a manufactured list of file names. 
		\item the ability to retrieve and save files to the simulated database, as described above. \\
	\end{itemize}
\end{enumerate}

Given access to this information, the test cases listed below will be able to exercise the \textsc{Synchronizer} module without building the entire system. 


\section{Acceptance and Black-Box Tests}
The following test cases are designed to validate the functionality that is specific to this module. We have derived the required functionality from the Component Specifications document, and our original requirements\footnote{This component changed during our design, so the initial requirements are somewhat out of date.  Instead of concentrating on iPods only, this component can synchronize with an array of personal devices.}. Please note that we do not wish to test the entire \textsc{Personal Device Exporter} component, just the \textsc{Synchronizer}. As such, the tests in this document do not validate each requirement listed at the relatively high level of abstraction found in the Component Specification document, they only test those applicable to the \textsc{Synchronizer} module. \\

\test
{Verify the ability to transfer data manually from the computer to the device.}
{Transfer a directory of files from the database stub to the device stub. The test program simulates the user's input, it will give the source and destination paths.}
{This test passes if the simulated computer database is unchanged, and the simulated device has the appropriate directory, with all files (preserved completely) in the specified location.}


\test
{Verify the ability to transfer data manually from the device to the computer.}
{Transfer a directory of files from the device stub to the database stub. The test program simulates the user's input, it will give the source and destination paths.}
{This test passes if the simulated device database is unchanged, and the simulated database has the appropriate directory, with all files (preserved completely) in the specified location.}

\test
{Verify the ability to automatically synchronize a device with a computer, when both the computer and device have files on them.}
{Given a stub for each component, synchronize the two versions of the database. No conflicts will exist, that functionality will be tested later.}
{This test passes if the databases on the device and component stubs are identical, and they are identical to the expected output.}

\test
{Verify the ability to automatically synchronize a device with a computer when there are files on the device but not on the computer}
{The same as the previous test, but have no files in the computer stub. }
{This test passes if the databases on the device and component stubs are identical, and exactly the same as the device was before the synchronization.}

\test
{Verify the ability to automatically synchronize a device with a computer when there are files on the computer but not on the device}
{The same as the previous test, but have no files in the device stub. }
{This test passes if the databases on the device and component stubs are identical, and exactly the same as the computer was before the synchronization.}


\section{White Box Design Testing}
In this section, we will enumerate the test cases that really exercise the module.  The tests in the previous section were designed to ensure that this component functions as desired, the tests in this section identify weaknesses in our design, and attempt to find problems.  The test cases are organized into subsections that  represent each method specified in the module design. \\


\subsection{synchronize}

\test
{Test this method when the device and computer are not acquainted, and the device is not supported.}
{Provide stubs that are not acquainted - the computer ID does not exist in the device's known computers list, and the device ID is not listed in the computer's known devices list. Also, do not include the stubbed device's model number in the list of supported devices.}
{This test passes if an appropriate error is given, and the synchronization process exits without crashing.}


\test
{Test this method when the device and computer are not acquainted, and the device is supported.}
{Provide stubs that are not acquainted - the computer ID does not exist in the device's known computers list, and the device ID is not listed in the computer's known devices list. When prompted, choose to overwrite the device's version of the database (the other options will be tested below).}
{This test passes if both versions of the database are identical to the version that was originally on the computer. }

\test
{Test this method when the device and computer are acquainted.}
{Give a device and database that are acquainted, and have made changes since the last sync (the other option will be exercised below). They will have non-empty databases. Provide no conflicts, those will be handled below.}
{This test passes if both versions after the sync are identical to the pre-determined output. }

\subsection{acquaintedWithComputer}

\test
{Test this method when the ID of the computer is not in the device's list of known computers, and the ID of the device is not in the computer's list of known devices.}
{In the stubbed version of these two components, make the above statement true.}
{This test passes if the method returns false.}

\test
{Test this method when the ID of the computer is not in the device's list of known computers, but the ID of the device is in the computer's list of known devices.}
{In the stubbed version of these two components, make the above statement true.}
{This test passes if the method returns false, and reports an error.}

\test
{Test this method when the ID of the computer is in the device's list of known computers, but the ID of the device is not in the computer's list of known devices.}
{In the stubbed version of these two components, make the above statement true.}
{This test passes if the method returns false, and reports an error.}


\test
{Test this method when the ID of the computer is in the device's list of known computers, and the ID of the device is in the computer's list of known devices.}
{In the stubbed version of these two components, make the above statement true.}
{This test passes if the method returns true.}

\subsection{supportedDevice}

\test
{Test this method when a given device is not supported.}
{Provide a stub of a device, whose model number is not in the list of supported devices in our database stub.}
{This test passes if the method returns false.}

\test
{Test this method when a given device is  supported.}
{Provide a stub of a device, whose model number is in the list of supported devices in our database stub.}
{This test passes if the method returns true.}

\subsection{firstSync}

\test
{Test this method when the user would like to manually synchronize files.}
{Provide a stub for the device and one for the database, both should be non-empty. When prompted by the main-program, our test-program should request manual synchronization, and then provide the various file source and destination paths provided. The test-progam should indicate that it has finished after it provides all source and destination files given. (Let all these files be valid, the boundary cases will be tested in the test cases that exercise the manualTransfer method.)}
{This test case passes if both versions of the database match the expected versions provided.}

\test
{Test this method when the user would like to automatically sync files, and the device has never been synchronized with another computer.}
{Provide a stub for a device that only provides a model and ID number; it has no files stored in the location Cue places its database. Also, there must be a stub for the computer database, which is non-empty.}
{This test passes if the resulting versions of the device and computer databases are identical, and they match the database provided initially.  Also, the new device must have added the computer to its list of known computers, and the computer must have added this device to its list of known devices.}

\test
{Test this method when the user would like to automatically sync, the device has been synchronized with some other computer before, and the user would like to overwrite the version of the database on the device, with the version on the computer.}
{Provide a stub for the database and computer where both databases are non-empty, but the two components are not acquainted (they do not include each other in their respective lists). When prompted, the test-program specifies that the device's database should be completely overwritten by the computer's database.}
{This test case passes if both versions of the database are identical to the computer's original version.  Also, the device must have added the computer to its list of known computers, and the computer must have added this device to its list of known devices.}

\test
{Test the same functionality as the previous test case, but overwrite the computer's database with the device's database, instead of the other way around.}
{Give the same setup, but when prompted, this test-case should indicate that the computer's database will be overwritten by the device's database.}
{This test case passes if both versions of the database are identical to the device's original version.  Also, the device must have added the computer to its list of known computers, and the computer must have added this device to its list of known devices.}

\test
{Test this method when the user would like to automatically sync, the device has been synchronized with some other computer in the past (but not this one), and the user would like to manually merge the two versions of the database. (Device chosen as master)}
{Give two stubs, as described in the previous two test-cases. When prompted, the test-case will indicate that a manual transfer of files is desired. We will provide a series of transfers that  make the device the master copy. Then we will indicate this so files are transfered as desired.}
{This test case passes if both versions of the database are identical to a pre-prepared version.  This version will be designed so that it is the image of the original device after the provided changes. Also, the device must have added the computer to its list of known computers, and the computer must have added this device to its list of known devices.}

\test
{The same as the previous test-case, but the computer's version of the database is chosen as the master copy}
{The setup will be the same, except the series of transfers given will make the computer the master copy.}
{The criteria is the same, except the pre-prepared expected copy will be created by taking the version on the computer, and performing the specified transfers.}

\subsection{manualTransfer}

It would be tedious to explicitly state each test-case for this method. We will describe each test to be run in a more concise fashion.  We must test each of the following: 
\begin{enumerate}
	\item copy and move
	\begin{itemize}
		\item when the source exists, and the file \emph{does not} exist in the destination path
		\item when the source exists, and the file \emph{does} exist in the destination path
		\item when the source does not exist, and the file \emph{does not} exist in the destination path
		\item when the source does not exist, and the file \emph{does} exist in the destination path
	\end{itemize}
	\item delete 
	\begin{itemize}
		\item when the file exists
		\item when the file does not exist 
	\end{itemize}
	\item rename
	\begin{itemize}
		\item when the file to be renamed exists and the new name is not taken
		\item when the file to be renamed does not exist and the new name is not taken
		\item when the file to be renamed exists and the new name is taken
		\item when the file to be renamed does not exist and the new name is taken
	\end{itemize}
\end{enumerate}

The acceptance criteria for these tests is fairly straight-forward.  If the scenario is viable, then the desired operation should be preformed. If the scenario is not viable (e.g. the file to be copied doesn't exist) then an error should be returned. 

\subsection{completeTransfer}

\test
{Test this method when the target is the device, and the computer's database is non-empty}
{Provide two non-empty stubbs, and indicate that the device is the target when prompted.}
{This test case passes if both versions of the database after the transfer are identical to the computer's version before the transfer}

\test
{Test this method when the target is the computer, and the device's  database is non-empty}
{Provide two non-empty stubbs, and indicate that the computer is the target when prompted.}
{This test case passes if both versions of the database after the transfer are identical to the device's version before the transfer}

Repeat the above tests when the source database is empty. 

\subsection{syncFiles}

\test
{Test this method when the computer and device are not out of sync.}
{Provide two stubs whose respective change logs are empty.}
{This test passes if the syncFiles method exits successfully without modifying any files.}

\test
{Test this method when the computer and device are out of sync}
{Provide two stubs that are out of sync.  (we will test the specifics of which one is out of sync below).}
{This test passes if both versions of the database after the sync are identical to a pre-determined expected version.}

\test
{Test this method when the computer and device are out of sync and update list is null.}
{Provide two stubs that are out of sync, and force getFileList to give a null list.}
{This test passes if the sync method exits without modifying either database. }


\subsection{outOfDateWithComputer}

\test
{Test this method when one of the change logs doesn't exist}
{Run this test twice, each time have one of the change logs not exist}
{These tests pass if the method returns an error, stating that these two devices are not acquainted. }

\test
{Test this method when both change logs are empty.}
{Provide two stubs whose change logs are empty.}
{This test passes if the method returns false. }

\test
{Test this when the computer's change log for the specified device is empty, but the change log for the computer on the device is non-empty.}
{Provide stubs that satisfy this scenario.}
{This test passes if the method returns true.}

\test
{Test this when the computer's change log for the specified device is non-empty, but the change log for the computer on the device is empty.}
{Provide stubs that satisfy this scenario.}
{This test passes if the method returns true.}

\test
{Test this method when both change logs are non-empty.}
{Provide stubs that satisfy this scenario.}
{This test passes if the method returns true.}

\subsection{getFileList}

% computer's change log empty
\test
{Test this method when the computer's change log is empty, but the device's change log is not.}
{Provide non-empty stubs that satisfy this.}
{This test passes if the returned list is the same as the non-empty list (that is the device's change log in this case).}
% device's change log empty
%both empty

\noindent
Repeat the above test when the device's change log is empty, and the computer's is not. This test passes  if the return value is the computer's change log.  Run the tests described above when there are no duplicate files in the non-empty change log, and when there are duplicates. Both should return the same list, described above. 

\noindent
Also, test this method when both are empty. This test passes if we return the empty list. \\

\test
{Test this method when files occur in both change logs (i.e. when there are conflicts)}
{Provide two stubs, whose change logs have conflicts.}
{This test passes if each conflict is appropriately added to the conflict list, and the sync occurs as expected.}


\subsection{manageConflicts}

\test
{Test this method when the user specifies that she would like to always keep the file with the newer time stamp}
{Provide a conflict list, and indicate the desired automatic handling when prompted.}
{This test passes when the resolved list matches the expected list. Specifically, the new of all files in the conflict list are placed in the resolved list. }


\test
{Test this method when the user wants to manually decide which files to keep.}
{Provide a change list that has several conflicts, including some delete conflicts.  Provide various responses when prompted for each file. We will respond that we want to keep a file from the computer, one from the device, and also specify that we do not want to decide now. For the delete conflicts, choose once to keep the file, once to delete it, and once to defer judgement.}
{This test case passes if the resolved list matches the expected list. Specifically, all files we decided to keep should be kept, and all files we decided to get rid of should be gone. If we deferred judgement, the two files (or one in the case of delete) should remain named appropriately. }

Test both of the above scenarios when the conflict list is empty. Both should return an empty list. Also test them when the conflict list is null.  We should return an empty list in that case as well, but alert the tester that a null list was used. 


\subsection{updateChangeLogs}

\test
{Test this method given a null list}
{Provide a null list, and a stub for the other components}
{This test passes if the method returns successfully, without modifying anything. The tester should be alerted that a null value was passed}

\test
{Test this method given an empty change list.}
{Provide two stubs and an empty change list.}
{This test passes if no files are changed.}

\test
{Test this method given a non-empty change list, where the computer and device each only have one change log.}
{Provide stubs that meet the above requirement and a non-empty change list.}
{This test passes if the change logs are wiped, and nothing else is modified.}

\test
{Test this method given a non-empty change list, where other change logs are present.}
{Provide two stubs, each must have additional change logs for other components, and a non-empty change log.}
{This test passes if the change log for the device, on the computer, is wiped and the change log for the computer, on the device, is wiped. Also, compare all other change logs to the expected versions. Specifically, anything that was changed on the computer during this sync must be reflected in the other change logs on that computer; the same is true for the device. }


\end{document}

ENDREP
id: 1y.0.r130/23871
type: file
pred: 1y.0.r115/6294
count: 2
text: 130 0 23846 23987 9810a10b8416a86547f592248d9d3753
props: 114 633 29 0 ff5c3c1f7bdb48ba0201950780ae7e31
cpath: /project4/lamottemitchell/test_cases.tex
copyroot: 0 /

PLAIN
K 9
index.txt
V 18
file 1x.0.r114/432
K 14
test_cases.tex
V 20
file 1y.0.r130/23871
END
ENDREP
id: 1w.0.r130/24206
type: dir
pred: 1w.0.r115/6624
count: 2
text: 130 24105 88 88 02d59407e7b9ee50f8183041d3428c13
cpath: /project4/lamottemitchell
copyroot: 0 /

PLAIN
K 15
lamottemitchell
V 19
dir 1w.0.r130/24206
K 7
sampson
V 18
dir 1z.0.r129/3166
END
ENDREP
id: 1v.0.r130/24468
type: dir
pred: 1v.0.r129/3417
count: 16
text: 130 24369 86 86 32debd55dee21c0b46234713decca586
cpath: /project4
copyroot: 0 /

PLAIN
K 8
project2
V 16
dir x.0.r41/3433
K 8
project3
V 17
dir y.0.r113/5763
K 8
project4
V 19
dir 1v.0.r130/24468
END
ENDREP
id: 0.0.r130/24742
type: dir
pred: 0.0.r129/3688
count: 130
text: 130 24616 113 113 266297f43bb19493d1390699ddf6e44e
cpath: /
copyroot: 0 /

1y.0.t129-1 modify true false /project4/lamottemitchell/test_cases.tex


24742 24883