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.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
