CSC/ECE 517 Fall 2009/program2 buddi wn: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
 
(29 intermediate revisions by 2 users not shown)
Line 1: Line 1:
'''Buddi Project'''
'''Buddi Project'''
== Important Information ==
* Submission: October 26 (Monday)
* First Feedback: October 30 (Friday)
* Resubmission: November 6 (Friday)
* Final Review: November 9 (Monday)
* Metareview: November 11 (Wednesday)
E-mail for Buddi questions:
wyatt@digitalcave.ca or wyatt.olson+buddi-ncsu@gmail.com.
=== Required Results ===
This project is more about QA and usability testing, rather than pure
development. While some coding may be required to enhance the view
layer, the vast majority of the code written will be in JUnit tests.
The following is required for your results:
# A '''.zip or .tgz archive''' containing the entire Buddi project (or at a minimum, all files which have changed OR a .diff of your changes, as you desire).
# A '''written report ([[Written Report on Model %28Testing%29|Model]]) on the model testing''', indicating what your unit tests test (paying attention to edge cases where problems are more likely to occur) and the results of these tests. (The actual unit tests themselves will be included in the archive in part a)
# A w'''ritten report ([[Written Report on View %28Testing%29|View]]) on the view testing''', indicating what tests you performed, and what the results were. Screenshots taken throughout the test procedure are optional, but a very good idea to demonstrate what problems (if any) you have found.
# '''A written report on what changes''' you have made to the view (or the model) as a result of your testing. If there were failures or potential improvements discovered in either your tests, this report should include a re-run of the failed tests, showing that they are now working.


== Objectives ==
== Objectives ==
# Verify that '''splits''' in the data model have been implemented correctly. Ensure that the API wrapper functions allow transparent access to the model. Ensure that there are no edge cases where data corruption occurs.  
 
# Refine and complete the '''view layer''', and verify that it works as desired in all cases.
=== Functionality ===
* Verify that '''splits''' in the data model have been implemented correctly. Ensure that the API wrapper functions allow transparent access to the model. Ensure that there are no edge cases where data corruption occurs.  
* Refine and complete the '''view layer''', and verify that it works as desired in all cases.
 
=== Testing ===
* Verify Model using JUnit.
There are already some model and API tests in the junit source folder - you can use these as a basis for creating more. You should construct some tests to only test the model, others to test the plugin API, and still others to verify that changes written to the API are accessible to the model (and vice-versa).
 
Be sure to test the edge cases and exceptional input, for instance:
what happens if you try to split a transaction 1000 ways?
What happens if you try to include 0 splits?
What happens when you try to pass null to various setter methods?
 
* Verify UI
Using your understanding gained from the model tests, you must construct written documents detailing what tests you are planning on doing, and how you plan to go about them. You must then carry out these tests, and document the results. In addition to data integrity, the view tests should include a usability component - is the way which split transactions are expressed intuitive? Are there better ways to do this?


== Bugs or Undesired Behaviors ==
== Bugs or Undesired Behaviors ==
Line 14: Line 49:
!  Expected Behavior
!  Expected Behavior
!  Solved
!  Solved
|-valign="top"
|  Default Amount for split
|  The default amount is not set to the difference automatically for the new split
|  Currently, default amount is set to zero
|  The remaining split amount represents the remaining balance among the splits
|  No
|-valign="top"
|  Category drop down
|  Category list not filtered
|  Some items (credit, cash) are not selectable when selecting a split source.
|  If it's not available for selection, then better take them off the list
|  No
|-valign="top"
|  Split From Source
|  Transaction involves split from sources didn't show the split when selected
|  It shows <From> in an unselected mode
|  Should show "split" entry with "..." button surfaced
|  No
|-valign="top"
|-valign="top"
|  Create New menu
|  Create New menu
Line 24: Line 77:
|  No
|  No
|-valign="top"
|-valign="top"
|  The "+", "-" buttons didn't appear naturally until one switched the focus TWICE after entering the amount.
|  Create Budget Category using existing category as parent
|   
|  From "My Budget" tab, "Edit" -> "Create Budget Category" -> create new category and choose one of the parents that does not have any children yet -> "OK".  
|   
|  Parent does not have + sign next to its name. It will only show up when you highlight parent's row or switch view from Buddi and come back.
|
|  Parent's name should have "+" sign next to it right after child creation.
|  No
|  No
|-valign="top"
|-valign="top"
Line 37: Line 90:
|}
|}


== Unit test ==
== References ==
 
=== CORRECT Boundary Conditions ===
 
Many bugs in code occur around "boundary conditions," that is, under conditions where the code's behavior may be different from the normal, day-to-day routine.
 
For instance, suppose you have a function that takes two integers:
<pre>
public int calculate(int a, int b) {
  return a/(a+b);
}
</pre>
Most of the time, this code will return a number just as you expect. But if the sum of a and b happens to equal zero, you will get an ArithmeticException instead of a return value. That is a boundary condition—a place where things might suddenly go wrong, or at least behave differently from your expectations.
 
To help you think of tests for boundary conditions, we'll use the acronym CORRECT:
 
* Conformance — Does the value conform to an expected format?
* Ordering — Is the set of values ordered or unordered as appropriate?
* Range — Is the value within reasonable minimum and maximum values?
* Reference — Does the code reference anything external that isn't under direct control of the code itself?
* Existence — Does the value exist (e.g., is non-null, non-zero, present in a set, etc.)?
* Cardinality — Are there exactly enough values?
* Time (absolute and relative) — Is everything happening in order? At the right time? In time?
 
Let's look at each one of these in turn. Remember that for each of these areas, you want to consider data that is passed in as arguments to your method as well as internal data that you maintain inside your method and class.
 
The underlying question that you want to answer fully is:
 
    <em>What else can go wrong?</em>


Once you think of something that could go wrong, write a test for it. Once that test passes, again ask yourself, "what else can go wrong?" and write another test, and so on.
* [[Unit Test for Buddi]]
* [[Buddi Existing Test code]]


== Useful Links ==
== Useful Links ==
# [http://devel.buddi.digitalcave.ca/en/ Buddi docs for Developers]
# [http://devel.buddi.digitalcave.ca/en/ Buddi docs for Developers]
# [http://buddi.digitalcave.ca/ Buddi docs for Users]
# [http://buddi.digitalcave.ca/ Buddi docs for Users]

Latest revision as of 19:45, 26 October 2009

Buddi Project

Important Information

  • Submission: October 26 (Monday)
  • First Feedback: October 30 (Friday)
  • Resubmission: November 6 (Friday)
  • Final Review: November 9 (Monday)
  • Metareview: November 11 (Wednesday)

E-mail for Buddi questions: wyatt@digitalcave.ca or wyatt.olson+buddi-ncsu@gmail.com.

Required Results

This project is more about QA and usability testing, rather than pure development. While some coding may be required to enhance the view layer, the vast majority of the code written will be in JUnit tests. The following is required for your results:

  1. A .zip or .tgz archive containing the entire Buddi project (or at a minimum, all files which have changed OR a .diff of your changes, as you desire).
  2. A written report (Model) on the model testing, indicating what your unit tests test (paying attention to edge cases where problems are more likely to occur) and the results of these tests. (The actual unit tests themselves will be included in the archive in part a)
  3. A written report (View) on the view testing, indicating what tests you performed, and what the results were. Screenshots taken throughout the test procedure are optional, but a very good idea to demonstrate what problems (if any) you have found.
  4. A written report on what changes you have made to the view (or the model) as a result of your testing. If there were failures or potential improvements discovered in either your tests, this report should include a re-run of the failed tests, showing that they are now working.

Objectives

Functionality

  • Verify that splits in the data model have been implemented correctly. Ensure that the API wrapper functions allow transparent access to the model. Ensure that there are no edge cases where data corruption occurs.
  • Refine and complete the view layer, and verify that it works as desired in all cases.

Testing

  • Verify Model using JUnit.

There are already some model and API tests in the junit source folder - you can use these as a basis for creating more. You should construct some tests to only test the model, others to test the plugin API, and still others to verify that changes written to the API are accessible to the model (and vice-versa).

Be sure to test the edge cases and exceptional input, for instance: what happens if you try to split a transaction 1000 ways? What happens if you try to include 0 splits? What happens when you try to pass null to various setter methods?

  • Verify UI

Using your understanding gained from the model tests, you must construct written documents detailing what tests you are planning on doing, and how you plan to go about them. You must then carry out these tests, and document the results. In addition to data integrity, the view tests should include a usability component - is the way which split transactions are expressed intuitive? Are there better ways to do this?

Bugs or Undesired Behaviors

Title Details Actual Behavior Expected Behavior Solved
Default Amount for split The default amount is not set to the difference automatically for the new split Currently, default amount is set to zero The remaining split amount represents the remaining balance among the splits No
Category drop down Category list not filtered Some items (credit, cash) are not selectable when selecting a split source. If it's not available for selection, then better take them off the list No
Split From Source Transaction involves split from sources didn't show the split when selected It shows <From> in an unselected mode Should show "split" entry with "..." button surfaced No
Create New menu Undesired behavior. Create new options shouldn't be put under Edit menu. It's not intuitive for new users. Under My Accounts tab, Edit -> Create Account.

Under My Budget tab, Edit -> Create Budget Category.

Several options:
  1. Move to under File menu
  2. Create button for "New Account" and "New Budget Category"
 No
Create Budget Category using existing category as parent From "My Budget" tab, "Edit" -> "Create Budget Category" -> create new category and choose one of the parents that does not have any children yet -> "OK". Parent does not have + sign next to its name. It will only show up when you highlight parent's row or switch view from Buddi and come back. Parent's name should have "+" sign next to it right after child creation. No
No

References

Useful Links

  1. Buddi docs for Developers
  2. Buddi docs for Users
Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/program2_buddi_wn&oldid=26457"