Form testing methodology
Moderators: Jon, Steve, Ian, Dave
-
- Ebase User
- Posts: 53
- Joined: Wed Jan 02, 2013 4:23 pm
- Location: Lyndhurst, Hampshire
- Contact:
Form testing methodology
I'm curious what processes people using for testing changes to more complex Ebase forms/systems. I'm finding that changing a script or part of a form can often have un-intended consequences and break other parts of the form. Running through the form functionality and trying various things often catches these problems but not always. Any pointers for doing this? Do you have a list of inputs / steps with expected results that you run through after making changes to make sure the form still works as intended?
0 x
- dvanhussel
- Ebase User
- Posts: 161
- Joined: Fri Oct 19, 2007 12:45 pm
- Location: Haarlem, the Netherlands
Re: Form testing methodology
A late reply..... I found this post with a search because I have basically the same question.
Until now we have tested manualy. Quit a lot of work but we caught most bugs in time. Recently our team has doubled in number of developers using Ebase (from 3 to 6). And more people are working on different forms depending on a single shared project.
When changes are made in this shared project, all depending forms should be tested. There are quit a lot of 'stable' forms that are not actively developed at the moment but are still run in prodction. All these forms should be tested again too.
Doing this manually is becomming a pain and we've had some issues merging changes and going in to producting where bugs where created by changes in the shared project.
Does Ebase staff have any recommendations on how we could automatically test our forms to find regressions introduced by changes in shared forms?
We are starting to use unit and integration testing in projects where other programming languages are used. It would be great if the same principles could be used in Ebase.
Until now we have tested manualy. Quit a lot of work but we caught most bugs in time. Recently our team has doubled in number of developers using Ebase (from 3 to 6). And more people are working on different forms depending on a single shared project.
When changes are made in this shared project, all depending forms should be tested. There are quit a lot of 'stable' forms that are not actively developed at the moment but are still run in prodction. All these forms should be tested again too.
Doing this manually is becomming a pain and we've had some issues merging changes and going in to producting where bugs where created by changes in the shared project.
Does Ebase staff have any recommendations on how we could automatically test our forms to find regressions introduced by changes in shared forms?
We are starting to use unit and integration testing in projects where other programming languages are used. It would be great if the same principles could be used in Ebase.
0 x
-
- Ebase Developer
- Posts: 27
- Joined: Tue Sep 18, 2007 3:21 pm
Re: Form testing methodology
The Ebase development team use a test framework based on Selenium Webdriver, HTMLUnit and JUnit. We are mainly interested in defending against regression bugs caused by changes to the Ebase software. We have quite a large number of test forms which are deployed to a tomcat server. These try to demonstrate all Ebase runtime functionality. We can then write JUnit tests which steer a webdriver 'browser', to simulate a user's mouse clicks and keypresses and check that everything is behaving correctly.
This sort of thing:
@org.junit.Test
public void testNavigatorInterfaceV4()
{
// Set up the test form
gotoTestForm("NAVIGATOR_TEST_V4");
Assert.assertTrue(navigator.pageContainsText("F1"));
navigator.clickTab("6");
Assert.assertTrue(navigator.pageContainsText("This is a text control"));
navigator.clickNextPage();
Assert.assertEquals("", navigator.controlValue("24", null));
navigator.clickLinkByText("Hyperlink");
Assert.assertEquals("link clicked!", navigator.controlValue("24", null));
navigator.clickImage("26");
Assert.assertEquals("image clicked!", navigator.controlValue("24", null));
navigator.clickButton("27", null);
Assert.assertEquals("button clicked!", navigator.controlValue("24", null));
navigator.clickNextPage();
// Button columns
Assert.assertEquals("BELMONT", navigator.controlValue("68", null));
navigator.clickTableCellButton("66", 2);
Assert.assertEquals("REDWOOD CITY", navigator.controlValue("68", null));
navigator.clickImage("67", 1);
Assert.assertEquals("BELMONT", navigator.controlValue("68", null));
}
The Navigator class consists of about 2000 lines of java code that knows how to read and control ebase HTML pages. This stuff took quite a while to create. However, it was the test plans, forms and junit code that took most effort. It works well for us.
This sort of thing:
@org.junit.Test
public void testNavigatorInterfaceV4()
{
// Set up the test form
gotoTestForm("NAVIGATOR_TEST_V4");
Assert.assertTrue(navigator.pageContainsText("F1"));
navigator.clickTab("6");
Assert.assertTrue(navigator.pageContainsText("This is a text control"));
navigator.clickNextPage();
Assert.assertEquals("", navigator.controlValue("24", null));
navigator.clickLinkByText("Hyperlink");
Assert.assertEquals("link clicked!", navigator.controlValue("24", null));
navigator.clickImage("26");
Assert.assertEquals("image clicked!", navigator.controlValue("24", null));
navigator.clickButton("27", null);
Assert.assertEquals("button clicked!", navigator.controlValue("24", null));
navigator.clickNextPage();
// Button columns
Assert.assertEquals("BELMONT", navigator.controlValue("68", null));
navigator.clickTableCellButton("66", 2);
Assert.assertEquals("REDWOOD CITY", navigator.controlValue("68", null));
navigator.clickImage("67", 1);
Assert.assertEquals("BELMONT", navigator.controlValue("68", null));
}
The Navigator class consists of about 2000 lines of java code that knows how to read and control ebase HTML pages. This stuff took quite a while to create. However, it was the test plans, forms and junit code that took most effort. It works well for us.
0 x
- dvanhussel
- Ebase User
- Posts: 161
- Joined: Fri Oct 19, 2007 12:45 pm
- Location: Haarlem, the Netherlands
Re: Form testing methodology
Hi Ben,
This looks very much like what we would want to do.
Is it possible to provide us with a copy of the Java classes of this test-framework that you have build?
That would save us a lot of time reinventing the wheel that you already invented
Regards,
David
This looks very much like what we would want to do.
Is it possible to provide us with a copy of the Java classes of this test-framework that you have build?
That would save us a lot of time reinventing the wheel that you already invented
Regards,
David
0 x
-
- Ebase Developer
- Posts: 27
- Joined: Tue Sep 18, 2007 3:21 pm
Re: Form testing methodology
I think I can probably let you have this. The problem is I have to do a little work to extract it from the rest of our testing system. Can you wait a couple of weeks?
0 x
Who is online
Users browsing this forum: No registered users and 11 guests