Getting test results & roadmap

[Christiaan van der Worp]

I have two questions. Hopefully someone can help me.

Where can I find the roadmap of cubictest?
&
How do I get the result from this junit test?


@Test
public void test() {
SeleniumRunner runner = new SeleniumRunner();
runner.setUseNewBrowserInstanceForEachTest(true);
runner.setUseExistingSeleniumServer("127.0.0.1", 9999);
runner.setMultiWindow(true);
BrowserType browser = BrowserType.INTERNET_EXPLORER;
runner.setBrowser(browser);
runner.runTests("/01_TestSuites/");
// !! How can I get the result !!
}

[Christian Schwarz]

If the test does not throw an exception, then the test has passed.

There is no roadmap for future development I'm afraid.

C.

2011/10/27 Christiaan van der Worp <chrisva...@gmail.com>

[Wim Heemskerk]

> There is no roadmap for future development I'm afraid.

Why is that? Too little time and too little help from the community?
Moved on to another way to GUI testing for the web?

I'd be most interested to hear about the intermediate to long term
future of Cubic. The departement I work for has been a Cubic user for
the last year or two and now finds itself at a crossroads. We want to
professionalize further but are running into bumps with Cubic. I came
here to look for the roadmap and to discuss how we might be able to
help out, but found a frightening quiet. What's up with that? Have we
missed the newer and greater way of working?

Our wish list in includes such things as:
- Recording support for the latest stable FireFox (as support from
Mozilla, such as security patches, for the version supported by Cubic
will not be available much longer)
- Future proof browser control via Webdriver (Selenium 2.0), as
Selenium RC has been deprecated.
- Passing in parameters from suite level through several levels and
passing them to custom steps (CT-49 & CT-83), as well as true looping
support for repeating the same test with different parameters
- Controlling the (un)checking of a check box via a parameter
- No changes to test files that aren't actually changing. Are these
changes caused by parameters stored in the test file? Anyway, they
make version control on the source code a messy affair.
- Refactoring support (renaming and moving (sub)tests around)
- (Improved) reporting of results when run via Maven from a CI server.
(This may be ignorance on our part, but we can't seem to get proper
feedback to the build server right now: the build passes despite test
failures.)

I'd love to hear the take on this from both leadership and community
members, as I think this great project needs next steps to not become
unusable through browsers and Selenium moving on. I'd love to help as
much as I can, but I already know taking lead on those major changes
is not in the cards for me. So, if no one is going to do that, we'd
have to look at other tools. I'd love to hear where Cubic users have
moved to and in what ways they like or dislike those tools.

[Christian Schwarz]

Thank you for your post.
You are right, Cubic is not being worked on by the original developers any more. This is mainly because of the overwhelmingly large task of creating a full-blown test editor supporting all kinds of scenarios and needs. The communitiy did not contribute very mich either.

Each time I have used Cubic myself on a real project, I have wished is was a programming language / API and not a GUI editor, as writing tests using a programming language does not limit you the way shortcomings of a tool limits you.
When using a programming language to write tests, you can build some necessary logic into the tests and use e.g. the PageObject pattern to reuse behaviour. There are good test libraries out there like WebDriver that lets you do this easily.

Cubic is an awesome editor, but for me I have realized that real programming is always king. At least that is what I have found out after many years of working with CubicTest.

In my day-to-day projects I have stopped using web tests alltogether, as they are slow and break too easily.

The best way to do new web application develpoment is by using an automated test suite at the unit and acceptance level. Both for back-end and front-end code. That typically requires test-driven development of all code, including front-end.

If that is not the case, then web-tests are necessary, and Cubic is an option here, but has the mentioned shortcomings.

If you still think Cubic is the way forward, then someone (other that the original developers) has to fork the project on GitHub and start developing again. It should not be too hard for a skilled developer to make it to work with the latest browsers and test libraries, but then again: You will always miss a real programming language. Custom Steps can only take you that far.

Or do you disagree? Cubic for the win?

Best regards
Christian Schwarz

2011/11/20 Wim Heemskerk <google...@gwaihir.net>

[Ye Mao]

hi, Christian Schwarz

I am YE Mao. Thank you for your nice reply. I agree with you totally that a Graphic Editor is not so efficient for an experienced programmer to make test script/code. 

However, since there are still many "amature" web testers who are not familiar with programming (unfortunately, it is true), I think a cool Graphic Editor like Cubic Test is quite useful, especially its "Recorder" and "Exporter". 

Currently, there are many such kind of testers in our company. Apparently it might cost too much time to train them into programming veteran, I want to introduce a extended Cubic Test to them to improve the work efficiency. Something valuable will be done to current CubicTest, like updating libraries, fixing bugs, supporting text based script editor, supportting continues integration, supportting export junit test code, encryptting password, ...). 

I already started the work in my free time. I want to share my work with people all over the world, so would you tell me how I can submit my changes to github ( I do not have authority to commit to your project ...) ?

Sincerely yours

Mao YE

2011年11月21日月曜日3時17分13秒 UTC+9 Christian Schwarz:

Thank you for your post.
You are right, Cubic is not being worked on by the original developers any more. This is mainly because of the overwhelmingly large task of creating a full-blown test editor supporting all kinds of scenarios and needs. The communitiy did not contribute very mich either.

Each time I have used Cubic myself on a real project, I have wished is was a programming language / API and not a GUI editor, as writing tests using a programming language does not limit you the way shortcomings of a tool limits you.
When using a programming language to write tests, you can build some necessary logic into the tests and use e.g. the PageObject pattern to reuse behaviour. There are good test libraries out there like WebDriver that lets you do this easily.

Cubic is an awesome editor, but for me I have realized that real programming is always king. At least that is what I have found out after many years of working with CubicTest.

In my day-to-day projects I have stopped using web tests alltogether, as they are slow and break too easily.

The best way to do new web application develpoment is by using an automated test suite at the unit and acceptance level. Both for back-end and front-end code. That typically requires test-driven development of all code, including front-end.

If that is not the case, then web-tests are necessary, and Cubic is an option here, but has the mentioned shortcomings.

If you still think Cubic is the way forward, then someone (other that the original developers) has to fork the project on GitHub and start developing again. It should not be too hard for a skilled developer to make it to work with the latest browsers and test libraries, but then again: You will always miss a real programming language. Custom Steps can only take you that far.

Or do you disagree? Cubic for the win?

Best regards
Christian Schwarz

[Christian Schwarz]

Hello!

You can fork CubicTest on GitHub and work / commit on that fork.

When you have useful features implemented, you can send pull requests
back to the main repo so that we can integrate your code.

After a while perhaps you can get direct access to the main CubicTest
repository :-)

C.