[Dev] Proposal for new automation architecture

[John Anderson]

Mikeal Rogers wrote:
>
> No, I'm saying that making sure that everything debugs in Wing in a 
> way that is usable for developers may be a 2.0 feature. I don't use 
> Wing so I don't know how much work that would be.
I suspect you're going to find that getting Chandler developers to write 
functional tests as they write Chandler will be one of the most 
efficient ways to develop Chandler. It's much like getting developers to 
write unittests as they write their code. So the functional tests are 
going to need to be maintained using tools that developers use, e.g. 
debuggers. Making it easy for developer will also encourage them to 
write more tests. Making it easy to debug in wing isn't hard and would 
probably have to be done by individual developers anyway, so it makes 
sense to do it once and share the effort.
> Ideally we want people in the community to be writing automated test 
> cases. Contributing QA to an open source project is usually the first 
> stage of contribution for most people, so writing test scripts for 
> Chandler should be easy for someone who is NOT a Chandler developer.
> The design of the framework and the upcoming changes to the Chandler 
> test library will be intended to make it as simple as possible for 
> anyone to write test scripts and should _not_ be targeted solely at 
> Chandler developers who are comfortable with the Chandler code base 
> and very comfortable with python. But the implementation will not make 
> it an uphill battle for Chandler developers to write automated test 
> cases either. We will be leveraging python in every way we can, and 
> all the methods we use for abstraction will be available via 
> inheritance for you to access directly. This way a developer, like 
> you, who is very familiar with CPIA and Chandler isn't limited by what 
> we've built abstraction for.
>
> Also we are trying to move away from Chandler automation being a 
> collection of small scripts using simple libraries to automate 
> functionality and make it easier for anyone to come on and write a 
> script that is useful for our automation system. If we are depending 
> on the users to handle the reporting and keeping track of state 
> themselves we can expect them to make mistakes and contribute scripts 
> that provide differing output from scripts written by people at OSAF.
For non-Chandler developers it probably makes more sense to have a way 
to record user actions to generate scripts. With a small amount of 
effort I think we could know whether this would be easy or difficult.