DELTA 145 0 350
SVN  ƒ ËZ
Êr€‚G h%€È+\documentclass[11pt,letterpaper]{article}
\usepackage[margin=1in]{geometry}

%\renewcommand{\labelenumi}{\arabic{section}.\arabic{enumi}.}
%\renewcommand{\labelenumii}{\arabic{section}.\arabic{enumi}.\arabic{enumii}.}

% LastModified: $Id$

\author{Brett McLarnon}
\title{
\textbf{Test Plan} \\
Calendaring Import/Export ModuleThe general testing strategy for the Calendaring Import and Export 
modules is to convert a known calendar into another format.  Existing 
tools (either provided by other pieces of Calendaring or by external 
libraries) are then used to iterate over both versions of the calendar 
to compare the events and todo items in each.  The differences must then 
be analyzed to determine whether the degree of lossyness is acceptable 
given the particular conversion: some formats are inherently less 
expressive than others, and so a lossless conversion is not always 
possible.  It is up to the specific test to determine whether any of the 
discrepancies are unjustified; if they are, the test should fail.  
Otherwise, the conversion is considered a success.

In addition, calendar imports are allowed to be lossy as long as they 
identify the places at which information loss occured.  This information 
must be checked to confirm that all instances of data loss were 
correctly flagged and that each instance is unavoidable---or at least 
acceptable.

The following tests are designed to be run in an existing xUnit 
complient automation framework.  The ultimate choice of which framework 
to use should depend on the implementation language of the Calendaring 
component; the test cases are described using pseudocode and generic 
xUnit terminology to remove language dependence and make simplify the 
process of porting them to desired framework, be it JUnit, CUnit, 
NUnit (for .NET), or some other similar tool.

\section{Stubbed Components}
Testing these modules requires that the Calendar, EventSeries, TodoList, 
TodoItem, and Pattern classes be implemented sufficiently to allow 
construction and data access.

Since these classes provide few methods other than their constructors 
and accessors, there is little benefit to developing separate stubbed 
versions.  Instead, the mainline versions can be branched; the methods 
necessary for testing import and export (the constructors and accessors) 
are very unlikely to contain bugs, and so it would be a waste of time to 
rewrite them.  The additional, more complicated methods these classes 
provide (such as conversion of Calendars to FixedCalendars) need not be 
implemented.  Thus, little to no time need be spent on constructing 
stubbed components, assuming that basics of the Calendar, EventSeries, 
TodoList, TodoItem, and Pattern classes have been implemented.  Note 
that the Pattern component must have all of the subclasses defined in 
\texttt{/tags/proj3/architecture/pattern/DESIGN}; import and export has 
its greatest dependence on Patterns, and these classes can not be 
effectively stubbed (any stub would have to implement most if not all of 
the functionilty of the real class).

\section{Acceptance Test Cases}
The following are component requirements developed during project 3 for 
the Calendaring Import/Export module\footnote{These requirements were 
taken verbatim from the CalendarImporter and CalendarExporter sections 
of \texttt{/tags/proj3/architecture/COMPONENT\_SPECIFICATION}.}:
\begin{itemize}
\item Import calendars from standard formats, creating the necessary 
Calendar and TodoList objects.
\item Provide easy addition of new import formats.
\item Export Calendars and TodoLists into standard formats.
\item Provide easy addition of new export formats.
\end{itemize}
The second and fourth requirement are subjective maintainability 
requirements rather than testable functional requirements; they are best 
confirmed using design review rather than automated testing.

The first and third requirements therefore become the basis for our 
acceptance test cases.  From these two requirements, we obtain the 
following tests to confirm that the component performs all the specified 
functions and handles obvious errors:
\begin{enumerate}
\item CalendarImporter
    \begin{enumerate}
    \item Each supported external format can be imported into a valid 
    Calendar and TodoList pair.
    \item An error is produced when an invalid calendar/todo list is 
    imported from each supported format.
    \end{enumerate}
\item CalendarExporter
    \begin{enumerate}
    \item A Calendar and TodoList pair exported to each supported format 
    conforms to the specification for that format.
    \item An error is produced when an invalid Calendar object is 
    exported to each supported format.
    \item An error is produced when an invalid TodoList object is 
    exported to each supported format.
    \end{enumerate}
\end{enumerate}

\section{Functionality Test Cases}
From the component specification\footnote{See the specification portions 
of \texttt{/tags/proj3/architecture/import\_export/DESIGN}.} we derive 
the following additional test cases:
\begin{enumerate}
\item CalendarImporter
    \begin{enumerate}
    \item Creating a CalendarImporter with an invalid import format 
    causes an exception to be thrown.
    \item For each import format, \texttt{import()} throws an exception 
    if the provided input stream is invalid.
    \item For each import format, malformed events and todo items are 
    flagged when a calendar is imported.
    \item Calling \texttt{import()} when no data has been added produces 
    an empty calendar.
    \item Multiple calls to \texttt{import()} combine the calendars.
    \item \texttt{getCalendar()} and \texttt{getTodoList()} return empty 
    Calendars and TodoLists, respectively, when no data has been 
    imported. 
    \item \texttt{getCalendar()} and \texttt{getTodoList()} return empty 
    Calendars and TodoLists, respectively, when empty calendars have 
    been imported. 
    \item The functions \texttt{getUnreadableEvents()} and 
    \texttt{getUnreadableTodoItems()} return the appropriate empty 
    objects when no unreadable events or todo items were imported.
    \item Consecutive calls to \texttt{getCalendar()}, 
    \texttt{getUnreadableEvents()}, \texttt{getTodoList()}, and 
    \texttt{getUnreadableTodoItems()} return the same results.
    \end{enumerate}
\item CalendarExporter
    \begin{enumerate}
    \item An exception is thrown when a CalendarExporter is constructed 
    with an invalid CalendarExportFormat.
    \item Multiple calls to \texttt{addCalendar()} combine the 
    calendars.
    \item Multiple calls to \texttt{addTodoList()} combine the todo 
    lists.
    \item \texttt{export()} throws an exception if the provided output 
    stream is invalid.
    \item Consecutive calls to \texttt{export()} produce the same results.
    \item \texttt{export()} produces an empty calendar if no data has
    been added.
    \item \texttt{export()} produces an empty calendar if empty 
    Calendars and TodoLists have been added.
    \item For each supported external format, the exported calendar 
    contains all the events in the Calendar object.
    \item For each supported external format, the exported calendar 
    retains as much information as the format allows about each event 
    (i.e., minimal lossiness).
    \end{enumerate}
\end{enumerate}

\section{White Box Test Cases}
Using the module design\footnote{See the design portions of
\texttt{/tags/proj3/architecture/import\_export/DESIGN}.}, we obtain the 
following white box test cases:
\begin{enumerate}
\item ICalendarImporter
    \begin{enumerate}
    \item Events with multiple recurrence strings and exclude dates do 
    not gain or lose dates when converted.
    \item Events with recurrences multiple times per day are imported 
    accurately (or flagged as unimportable).
    \end{enumerate}
\item ICalendarPatternImporter
    \begin{enumerate}
    \item For each Pattern type, an equivalent recurrence string is 
    generated.
    \item Exception dates are transferred from the Pattern object to the 
    recurrence.
    \end{enumerate}
\item ICalendarExporter
    \begin{enumerate}
    \item \texttt{export()} throws an exception if the provided output 
    stream is invalid.
    \end{enumerate}
\item ICalendarPatternExporter
    \begin{enumerate}
    \item An exception is generated when an empty/invalid recurrence is 
    provided.
    \item An UnrepresentableRecurence exception is thrown when an 
    unrepresentable recurrence is imported.
    \item For each type Pattern type, a recurrence that should generate 
    that Pattern type does so.
    \item A recurrence pattern that requires multiple Pattern objects to 
    represent is properly imported.
    \item Exception dates are properly carried over to the resulting 
    Pattern.
    \item Exception dates are properly carried over to the resulting 
    Patterns objects when multiple are needed to represent the 
    recurrence.
    \item An exception is thrown when a recurrence with invalid 
    exception dates is provided.
    \end{enumerate}
\item ICalendarDataTimeConverter
    \begin{enumerate}
    \item \texttt{dateFromString()}, \texttt{timeFromString()}, and 
    \texttt{dateTimeFromString()} throw an exception when the provided 
    string is not a valid UTC time.
    \item Conversions of ``normal'' dates (in both directions) are 
    consistent and correct.
    \item Conversions of distant dates (far past and far future) are 
    consistent and stable.
    \end{enumerate}
\end{enumerate}

\end{document}
ENDREP
id: 17.0.r152/9631
type: file
pred: 17.0.r151/5386
count: 4
text: 152 0 9608 9690 d24eb38ab4542f17b46264be5cc241f4
props: 145 363 66 0 6ba7dd82ad93517d00415b716ccdc1bf
cpath: /trunk/testing/brett/testPlan.tex
copyroot: 0 /

PLAIN
K 12
testPlan.tex
V 19
file 17.0.r152/9631
END
ENDREP
id: 16.0.r152/9915
type: dir
pred: 16.0.r151/5670
count: 4
text: 152 9855 47 47 f4f9e27d767feb5b01634bfb0461eb03
props: 145 701 54 0 2861bd3d36f04f7976bb7db1d611bdb5
cpath: /trunk/testing/brett
copyroot: 0 /

PLAIN
K 5
brett
V 18
dir 16.0.r152/9915
K 4
mike
V 18
dir 18.0.r150/1261
END
ENDREP
id: 15.0.r152/10208
type: dir
pred: 15.0.r151/5963
count: 7
text: 152 10124 71 71 737e4adff3ad76a9b6b86b8328b15360
cpath: /trunk/testing
copyroot: 0 /

PLAIN
K 12
architecture
V 18
dir m.0.r132/10273
K 12
requirements
V 16
dir j.0.r53/2435
K 7
testing
V 19
dir 15.0.r152/10208
END
ENDREP
id: 3.0.r152/10496
type: dir
pred: 3.0.r151/6248
count: 136
text: 152 10360 123 123 94e6527006388c575663e2e84182d26f
cpath: /trunk
copyroot: 0 /

PLAIN
K 8
branches
V 17
dir 1.0.r143/2096
K 4
tags
V 16
dir 2.0.r144/236
K 5
trunk
V 18
dir 3.0.r152/10496
END
ENDREP
id: 0.0.r152/10760
type: dir
pred: 0.0.r151/6509
count: 152
text: 152 10642 105 105 c00c6f21106bc6c1a8d7bf701771d7d0
cpath: /
copyroot: 0 /

17.0.t151-1 modify true false /trunk/testing/brett/testPlan.tex


10760 10901