Question about manual test pages

[Colin Clark]

Hey all,

Based on Anastasia's feedback and a conversation between Justin and I,  
here are the decision we've made for the manual tests. In most cases,  
we've decided to keep these tests only for as long as it takes us to  
create Starting Points or unit tests. In many cases, they're ugly and  
confusing, but they illustrate interesting functionality in our code.  
We want to share these with our users in a more polished way.

Here's the list:

InlineEdit: keep for now
	- need to resolve the Starting Point with the manual test
		- eg. custom invitation text, many in a row, etc.
	- rich text and drop down need their Starting Point or standalone-demo

Table of Contents: keep for now
	- promote to its own Starting Point

Progress: keep for now
	- need Starting Point for Progress

Scroller: keep for now
	- keep it as a manual test until we figure out how to unit test it

Renderer: keep most for now
	- useful for learning the renderer, so we should convert to Starting  
Points
	- nix Object Entry
	- consolidate Component Types and Radio Buttons
	- all Starting Points should programmatically generate trees
	
Reorderer: remove most, promote table reorderer immediately
	- nix:
		- simple portlets
		- permissions
		- simple list
		- simple grid
		- multiple reorderer
		- nested reorderer

	- convert to unit test:
		- dynamic reorderer

	- convert to a sakai integration-demo:
		- table reorderer

Menubar: remove
	- nix

Multiple versioning: convert to a unit test
	- convert to a unit test
		- should we also test multiple version of jQuery?

anchors.html:
	- boot to the "escalate" directory

Colin


On 27-Mar-09, at 12:09 PM, Anastasia Cheetham wrote:

>
>> Remove:
>> Inline Edit: Simple Text
>
> We should double-check whether or not the starting-point actually  
> covers all of the possible configurations covered by this manual  
> test before deleting it.
>
>
>> Remove:
>> Reorderer: Simple Grid
>>
>
>
>> Remove:
>> Reorderer: Nested Reorderers
>
> Do we have any other example of nested reorderers? If not, we  
> shouldn't delete this - we should clean it up and promote it.
>
>
>> Don't know:
>> Renderer: Component-types
>
> This is not ready for promotion yet, but I think it should continue  
> to exist. It's been helpful for my learning, and will probably serve  
> as a starting point for promotion soon.
>
>> Don't know:
>> Renderer: Object-data-entry
>
> Toss it.
>
>> Don't know:
>> Renderer: Radio Buttons
>> Renderer: Test Renderer
>> Renderer: Tree Generation
>
> I'd appreciate it if these weren't tossed. Maybe all of these  
> renderer files should be moved into the sandbox, if we want to get  
> rid of manual test files??

---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org