Help us test the .NET Bridge!

Posted by sarahm on 29-Apr-2010 14:21

As you know, the current license agreement restricts the use of the OpenEdge .NET Bridge to classes relevant to UI.  However many of you have expressed interest in using non-UI classes in your development.  We are therefore starting to take a look at the feasibility of lifting this restriction.
We are beginning a test project to validate the .NET Bridge with non-UI controls.  A huge component of this project involves you!  This is your opportunity to collaborate with our QA team and create a suite of tests that exercises the .NET Bridge with native .NET components that are not necessarily UI components.
The QA team is extending to you an invitation to participate in a Testing the Bridge program by contributing test cases and code samples to our suite of .NET tests.  We are giving you the go-ahead to try what you want and share it with us – both successes and failures.  We believe the software you have in your hands today is ready to handle these types of cases.
What’s in it for you?  By participating in this program you are contributing the test cases that matter most to you.  Test code that you submit will be added to our automated test suite and ensure the quality of the product is high and remains high for the scenarios you care about.  Your submission contributes to the overall quality of the final product, which is a win for you!
What’s in it for us?  We continue to build automated test suites to cover a wide range of scenarios.  However the test cases that matter most are the ones you intend to execute during your development.  So while our QA team works to cover as many cases as possible, we are not you.  Automating your test cases will give us more information about the kinds of things you are doing that we can apply now and to future development and test design.
So how does it work?  We are running the program for 60 days, from May 5, 2010 to July 2, 2010.  If you intend to participate send an email to TestingTheBridge@progress.com describing who you are and what you intend to test.  We’ll follow up with details about the program and how to submit your test plan and your code.  Then, as you test, zip up your code and submit to the alias for inclusion in our test bed.  You may also submit via the forum if you wish.  Our QA engineers will be monitoring the forums and the alias for submissions, discussions and questions, and may contact you regarding your testing.  Of course if you encounter bugs, submit those too! 
Keep in mind, this is a test project and, as such, does not represent a supported product.  Therefore Technical Support will not be in a position to assist you.  But please don’t hesitate to ask for assistance via the alias or the forum.  Also, lifting this EULA restriction only applies to this test program; you may not develop anything you intend to deploy that does not comply with the current license agreement.  We will consider the results of this project when deciding whether or not to formally lift this restriction in an upcoming release.

Look for a program kick-off on May 5!

OpenEdge Development - Forum

All Replies

Posted by Admin on 29-Apr-2010 14:46

Hi Sarah, just that we get this right. This initiative is about (stress) testing the current bridge and to design test scenarios for you? That's great and I'm sure may here are willing to support that!

Just to get this clear. This initiative is not about bringing the bridge to TTY (batch) clients or the AppServer, right? Or are you interested in use cases for that as well?

We believe the software you have in your hands today is ready to handle these types of cases.

So no AppServer or TTY (batch) client this time, right?

Posted by Admin on 29-Apr-2010 17:06

As you know, the current license agreement restricts the use of the OpenEdge .NET Bridge to classes relevant to UI. 

Sarah, this question keeps my grey cells active right now!

How do you define "classes relevant to UI"? I assume that System.IO.Directory, System.Net or System.Xml classes are not relevant to the UI. How about using System.Drawing.Image for image manipulation (i.e. adding transparency to an image, overlaying a base image with something like a label decoration in Eclipse). How do you define that? Which classes do you already test?

Should we leave out classes that may need multi-threading like message queue interfaces or hardware interfaces because that's a different topic/issue than non-UI classes?

Posted by Thomas Mercer-Hursh on 30-Apr-2010 11:24

Can't you use the existing functionality to test use cases that would be among those you would use if you did have AppServer availability?  E.g., I remember some messaging thing that Julian was wanting to do before he found out he couldn't do it on the AppServer.  He could still test how it worked in a client and then use that as an argument for enabling it in the AppServer in a future release.  No?

Posted by Admin on 30-Apr-2010 13:56

Can't you use the existing functionality to test use cases that would be among those you would use if you did have AppServer availability?

Probably yes and no.

The use cases are certainly different on both ends, i.e. supporting tasks for the UI vs. EAI. Not all the possible use cases might already have been modelled or thought thru. So knowing the scope of this initiative might help us save some time or get attracted to spend even more time.

Posted by Thomas Mercer-Hursh on 30-Apr-2010 14:44

Seems to me that the initiative is in our hands.  If we have server-side things we want to use this for, then we should test how the relevant classes work with the existing product and make our case for why we would want to do this on the server.

Posted by dlauzon on 03-May-2010 09:55

For some reason, the Progress email server ntmamx2.progress.com refused my email (there is no attachment in this email, by the way).

Here's the error:

ntmamx2.progress.com #<TestingTheBridge@progress.com>> #SMTP#

Any idea?

Posted by sarahm on 03-May-2010 11:16

There are really two separate ideas here -- the first is the implementation of the Bridge on the AppServer and the second is lifting the EULA restriction on the GUI for .NET product that is in your hands today.

Implementing the Bridge on the AppServer is a project unto itself and we understand the need for it -- we are completely on your side and it is definitly something we are considering.  Those use cases are not what we are looking for here because we cannot implement those test cases at the moment.  The product does not support it.

What we are working on here is the feasibility of lifting the restrictions imposed by the license agreement for cases that should work with the current product.  These test cases can be implemented into our test suite today.  This does include the GUI batch client (it is not implemented in the TTY client).  The value of collecting these test cases is to broaden our test bed to include more of the scenarios that are important to you, and give us some background on the kinds of use cases we should be thinking about when we design our tests.

I hope that answers some of your questions.  The alias should be active on May 5, so try again then!  And look for more information at that time.

Posted by Admin on 03-May-2010 11:26

I hope that answers some of your questions.  The alias should be active on May 5, so try again then!  And look for more information at that time.

Hello Sarah! That was exactly the clarification I was waiting for and more or less have been expecting.

Thanks!

Mike

This thread is closed