Testing strategies for ADF Projects
270 views
Skip to first unread message
Nathalie Roman
Sep 18, 2009, 3:40:26 AM9/18/09
to ADF Enterprise Methodology Group
We're approaching OOW rapidly, and we're discussing the different
topics that can be adressed during the ADF EMG Sessions.
One of the topics I would like to start discussing in this group, is
the testing strategies that are used at the different project sites.
In most projects we're now trying to introduce Test Driven
Development, to make sure that all functionality that is integrated
within the project lifecycle is thouroughly tested before releasing
the code into the release management lifecycle.
What does it mean Test Driven Development :
Each new feature begins with writing a test, which will inevitably
fail because it is written before the feature has been implemented. To
write a test, the developer must clearly understand the feature's
specification and requirements. This could also imply a variant, or
modification of an existing test.
This is a differentiating feature of test-driven development versus
writing unit tests after the code is written: it makes the developer
focus on the requirements before writing the code, a subtle but
important difference.
At our current ADF project most developers we're already acquanted
with Unit-testing code and had no difficulties with the TDD-approach.
The benefits for the project:
1) Better communication and collaboration between the business
analyst, product owner and development team
2) Code was much more failproof and the team could easily delegate
tasks amongst each other. E.g. one developer wrote the tests and the
other member of the team implemented the functionality.
Limitations:
1) When deadlines and production dates are approaching, it's hard to
keep the team focussed on this approach. It's in everyone's mindset
that refactoring test cases and creating new ones, will take up time
that is limited, instead of just writing the code, or changing it and
pushing it through release management
2) The tests themselves become overhead for the maintenance part of
the project.
3) Test cases aren't bullet-proof, if the code and test cases don't
cover the functional requirements, it won't be shown in the testing
results. As well functional and business validation is needed before
you can be sure the implemented functionality is bullet-proof.
What I would like to know from you all:
1) Which testing approach is used?
2) What were the benefits and limitations you've encountered?
Would it be interesting to talk about TDD at the ADF EMG session, or
would you like to discuss another methodology or approach?
Kind regards,
Nathalie
topics that can be adressed during the ADF EMG Sessions.
One of the topics I would like to start discussing in this group, is
the testing strategies that are used at the different project sites.
In most projects we're now trying to introduce Test Driven
Development, to make sure that all functionality that is integrated
within the project lifecycle is thouroughly tested before releasing
the code into the release management lifecycle.
What does it mean Test Driven Development :
Each new feature begins with writing a test, which will inevitably
fail because it is written before the feature has been implemented. To
write a test, the developer must clearly understand the feature's
specification and requirements. This could also imply a variant, or
modification of an existing test.
This is a differentiating feature of test-driven development versus
writing unit tests after the code is written: it makes the developer
focus on the requirements before writing the code, a subtle but
important difference.
At our current ADF project most developers we're already acquanted
with Unit-testing code and had no difficulties with the TDD-approach.
The benefits for the project:
1) Better communication and collaboration between the business
analyst, product owner and development team
2) Code was much more failproof and the team could easily delegate
tasks amongst each other. E.g. one developer wrote the tests and the
other member of the team implemented the functionality.
Limitations:
1) When deadlines and production dates are approaching, it's hard to
keep the team focussed on this approach. It's in everyone's mindset
that refactoring test cases and creating new ones, will take up time
that is limited, instead of just writing the code, or changing it and
pushing it through release management
2) The tests themselves become overhead for the maintenance part of
the project.
3) Test cases aren't bullet-proof, if the code and test cases don't
cover the functional requirements, it won't be shown in the testing
results. As well functional and business validation is needed before
you can be sure the implemented functionality is bullet-proof.
What I would like to know from you all:
1) Which testing approach is used?
2) What were the benefits and limitations you've encountered?
Would it be interesting to talk about TDD at the ADF EMG session, or
would you like to discuss another methodology or approach?
Kind regards,
Nathalie
florin pop
Sep 18, 2009, 5:55:02 AM9/18/09
to adf-met...@googlegroups.com
We are doing tests after the code was written because one of things is that many times CR/BR are changed/altered on the fly ... so it is pointless to do tests on something that will probably change.
2009/9/18 Nathalie Roman <lieke...@gmail.com>
Aino
Sep 18, 2009, 5:47:18 PM9/18/09
to adf-met...@googlegroups.com
Hi,
We apply different approaches.
At least, we have basic unittests for all viewobjects. Just an executeQuery, to determine some discrepancies between the VO and the database objects. We have a basic framework for it to have a test created in minutes.
In addition, the implementation of business logic in the vo can also often is also subjected to unittests.
For entity objects, we often write unittests for validators and method validation, especially when handling dates. Although, for dates we use some common, reusable, classes that are subject to unittests themselves. In my opinion it is almost always a good idea to put business logic in their own, re-usable and testable, classes.
I agree that by applying TDD developers focus more on functionality and that they think more about how and where to implement business logic. In this way, the implementation changes less than without TDD. It will result in clearer code, that is also better to test.
In my experience, writing tests after writing code, often results in not writing tests.
By the way, a side effect of writing unittests is that it also increases your knowledge about the ADF framework.
A last remark, is that a unittest often provides a much faster way to write and debug code, instead of everytime starting up the application, navigate to the right page and check the result.
Ciao
Aino
Jan Vervecken
Sep 19, 2009, 7:03:49 AM9/19/09
to ADF Enterprise Methodology Group
hi
A challenge when writing JUnit tests on ADF Business Components, is
dealing with its strong dependency on a database.
Typically it has to be there when you run your tests (in JDeveloper,
in a continuous integration environment, ...) and it has to be in an
expected state for your tests to succeed.
Are there any good strategies to deal with this database dependency
for JUnit tests, or maybe even to avoid this dependency?
many thanks
Jan Vervecken
A challenge when writing JUnit tests on ADF Business Components, is
dealing with its strong dependency on a database.
Typically it has to be there when you run your tests (in JDeveloper,
in a continuous integration environment, ...) and it has to be in an
expected state for your tests to succeed.
Are there any good strategies to deal with this database dependency
for JUnit tests, or maybe even to avoid this dependency?
many thanks
Jan Vervecken
ugb
Sep 19, 2009, 1:35:19 PM9/19/09
to ADF Enterprise Methodology Group
hi,
i try to bring tdd into my adf, database projects or workshops. The profit of doing tdd is most developers clear, but in the end following facts coming up:
1.) there is no time anymore for writing Tests
2.) developer skills in one
team are sometimes to different ( 20years forms/
plsql up to junior developer direct from university) -
you have to teach metholody
3.) Testdata has changed by other developer. Is it hard and complex to set up this data -
this test will never run again.
With this points
in mind i try the maximum of the following guide lines:
a) use tdd so often you can. Test first...
b) for every new bug: first write a test .
The bug can be close when the test is correct.
This make sure you have the fixed bug never again.
The test can be a
database package unit test, a junit adf bc test or a selenium ui test. From my expirence you need tests for all layers.
Debugging bc model service from a junit test code is simpler than from
ui.
When you implement the use cases of the ui, it is faster you record
your user interaction with selenium and every time you go back to the
dialogs you can automate the login, menu selection or other user
input. Think how often you start a application, login etc. on one day
of ui development.
c) virt. test environment to save your testdata and startpoint. Every Night we go back to a special snapshot and run our Nightly Build with all tests.
d) Set up a CI Server - we use hudson -
it runs with generated ant scripts from jdeveloper with a little
modification in 20 min
e) adf bc: Test every vo to found out database changes.
:
There are many points more but the most importent fact is: keep test writing and runing easy, so that every developer can use and understand it.
I will talk about our adf development and
test environment on my DOAG presentation in Nürnberg.
Uli
i try to bring tdd into my adf, database projects or workshops. The profit of doing tdd is most developers clear, but in the end following facts coming up:
1.) there is no time anymore for writing Tests
2.) developer skills in one
team are sometimes to different ( 20years forms/
plsql up to junior developer direct from university) -
you have to teach metholody
3.) Testdata has changed by other developer. Is it hard and complex to set up this data -
this test will never run again.
With this points
in mind i try the maximum of the following guide lines:
a) use tdd so often you can. Test first...
b) for every new bug: first write a test .
The bug can be close when the test is correct.
This make sure you have the fixed bug never again.
The test can be a
database package unit test, a junit adf bc test or a selenium ui test. From my expirence you need tests for all layers.
Debugging bc model service from a junit test code is simpler than from
ui.
When you implement the use cases of the ui, it is faster you record
your user interaction with selenium and every time you go back to the
dialogs you can automate the login, menu selection or other user
input. Think how often you start a application, login etc. on one day
of ui development.
c) virt. test environment to save your testdata and startpoint. Every Night we go back to a special snapshot and run our Nightly Build with all tests.
d) Set up a CI Server - we use hudson -
it runs with generated ant scripts from jdeveloper with a little
modification in 20 min
e) adf bc: Test every vo to found out database changes.
:
There are many points more but the most importent fact is: keep test writing and runing easy, so that every developer can use and understand it.
I will talk about our adf development and
test environment on my DOAG presentation in Nürnberg.
Uli
florin.marcus
Sep 20, 2009, 1:30:52 PM9/20/09
to ADF Enterprise Methodology Group
Hi,
I am using TDD methodologies in the last 5 years and I do think that
is the best approach out there for developing complex applications.
I only want to add two things:
1. Even if you succeed to implement TDD as a formal procedure, some of
the experienced developers will remain stuck with the traditional
approach of writing code. They will only write tests because they have
to.
2. TDD is also about the quality of the application design. If you
might encounter difficulties on making your code testable, it could
mean that your code is not following a good separation of business
from the presentation. With ADF, such example of anti-pattern is
writing business logic in backing beans instead of using custom
methods in application module.
I am using TDD methodologies in the last 5 years and I do think that
is the best approach out there for developing complex applications.
I only want to add two things:
1. Even if you succeed to implement TDD as a formal procedure, some of
the experienced developers will remain stuck with the traditional
approach of writing code. They will only write tests because they have
to.
2. TDD is also about the quality of the application design. If you
might encounter difficulties on making your code testable, it could
mean that your code is not following a good separation of business
from the presentation. With ADF, such example of anti-pattern is
writing business logic in backing beans instead of using custom
methods in application module.
Nathalie Roman
Sep 21, 2009, 5:01:57 AM9/21/09
to ADF Enterprise Methodology Group
Hi Florin,
If you don't write your tests beforehand, you wont be able to have an
idea of the dependencies and impact on existing code when you
implement a change request or new business requirement. That's where
TDD, continious integration, selenium testing proves it's value.
When you first implement your testing strategies and test classes, the
developer will now exactly which business requirements need to be
implemented and can test End-2-End each time new operations/methods
are implemented. If a CR or BR than needs to be implemented, you can
test the impact and dependencies with a single click. In other words,
your testing approach will give as well the development team as
management more insight into impact analysis and you will have a more
errorprone E2E project lifecycle.
If you have a look at the project you're talking about, isn't it hard
to achieve your deadlines for each CR or BR because you don't know
which existing functionalities are impacted?
Kind regards,
Nathalie
On Sep 18, 11:55 am, florin pop <pop.florin.nico...@gmail.com> wrote:
> We are doing tests after the code was written because one of things is that
> many times CR/BR are changed/altered on the fly ... so it is pointless to do
> tests on something that will probably change.
>
> 2009/9/18 Nathalie Roman <liekero...@gmail.com>
> > Nathalie- Hide quoted text -
>
> - Show quoted text -
If you don't write your tests beforehand, you wont be able to have an
idea of the dependencies and impact on existing code when you
implement a change request or new business requirement. That's where
TDD, continious integration, selenium testing proves it's value.
When you first implement your testing strategies and test classes, the
developer will now exactly which business requirements need to be
implemented and can test End-2-End each time new operations/methods
are implemented. If a CR or BR than needs to be implemented, you can
test the impact and dependencies with a single click. In other words,
your testing approach will give as well the development team as
management more insight into impact analysis and you will have a more
errorprone E2E project lifecycle.
If you have a look at the project you're talking about, isn't it hard
to achieve your deadlines for each CR or BR because you don't know
which existing functionalities are impacted?
Kind regards,
Nathalie
On Sep 18, 11:55 am, florin pop <pop.florin.nico...@gmail.com> wrote:
> We are doing tests after the code was written because one of things is that
> many times CR/BR are changed/altered on the fly ... so it is pointless to do
> tests on something that will probably change.
>
>
> - Show quoted text -
Nathalie Roman
Sep 21, 2009, 5:42:30 AM9/21/09
to ADF Enterprise Methodology Group
Hi Uli,
Thanks for sharing your approach and experiences in regards to testing
strategies.
Will you be attending OOW as well? It would be great if you could
present a short summary of your presentation you will be giving at
DOAG.
Kind regards,
Nathalie
Thanks for sharing your approach and experiences in regards to testing
strategies.
Will you be attending OOW as well? It would be great if you could
present a short summary of your presentation you will be giving at
DOAG.
Kind regards,
Nathalie
Nathalie Roman
Sep 21, 2009, 5:54:18 AM9/21/09
to ADF Enterprise Methodology Group
Hi Marcus,
Thanks for sharing your experiences in regards to TDD and some of the
pitfalls as well.
In regards to you first remark, experienced developers remaining stuck
with their traditional approach, I don't think that's a big problem.
It's all about having a different mindset and choosing a strategy and
approach which is a best fit for as well the team, management as the
customer.
If developers aren't acquanted with testing strategies, they can learn
it on the job, through knowledge sharing with developers familiair
with the approach and trail-and-error. I do think, when you start
using TDD or testing approaches, you will soon experience the benefits
as well in project duration as stability in terms of new releases,
change in team-members, etc.
When you're familiar with a certain way of thinking, working ... it's
always a little bit hard to think outside of the box and give another
approach a try, but the main goal will always be to build up the
knowledge and experience in the team and to reach your deadlines in
team. I think TDD, continious integration and regression testing will
always be an added value ...
I fully agree with your second remark, TDD will guide you in designing
your application as well. When you've implemented business logic
inside backing beans, you won't be able to test your business logic
E2E at the business level and will only show up during your selenium
tests or at the presentation level.
Thanks again for sharing these insights!
Kind regards,
nathalie
Thanks for sharing your experiences in regards to TDD and some of the
pitfalls as well.
In regards to you first remark, experienced developers remaining stuck
with their traditional approach, I don't think that's a big problem.
It's all about having a different mindset and choosing a strategy and
approach which is a best fit for as well the team, management as the
customer.
If developers aren't acquanted with testing strategies, they can learn
it on the job, through knowledge sharing with developers familiair
with the approach and trail-and-error. I do think, when you start
using TDD or testing approaches, you will soon experience the benefits
as well in project duration as stability in terms of new releases,
change in team-members, etc.
When you're familiar with a certain way of thinking, working ... it's
always a little bit hard to think outside of the box and give another
approach a try, but the main goal will always be to build up the
knowledge and experience in the team and to reach your deadlines in
team. I think TDD, continious integration and regression testing will
always be an added value ...
I fully agree with your second remark, TDD will guide you in designing
your application as well. When you've implemented business logic
inside backing beans, you won't be able to test your business logic
E2E at the business level and will only show up during your selenium
tests or at the presentation level.
Thanks again for sharing these insights!
Kind regards,
nathalie
Florin Marcus
Sep 22, 2009, 2:01:00 PM9/22/09
to ADF Enterprise Methodology Group
Hi Natalie,
I have noticed that you mentioned Selenium as part of your acceptance
testing procedure.
Can you give some insights from your experience using automated
acceptance testing?
Thanks,
Florin Marcus
I have noticed that you mentioned Selenium as part of your acceptance
testing procedure.
Can you give some insights from your experience using automated
acceptance testing?
Thanks,
Florin Marcus
Nathalie Roman
Sep 24, 2009, 7:58:53 AM9/24/09
to ADF Enterprise Methodology Group
Hi Marcus,
Thanks for your interest!
The automated acceptance testing is a huge improvement as well from
the developer as the business viewpoint.
The team, product owner and business have insight on the testing
results and developers now immediatly which code is impacted/broken
when new functionality is added or existing functionality is changed.
As well the unit testing, as automated testing and nightly builds
greatly improve the stability of the environment, especially because
we have a lot of dependencies to third-party services. The application
integrates with a document management system, third party web
services, external data sources, ...
Kind regards,
Nathalie
> > > - Show quoted text -- Hide quoted text -
Thanks for your interest!
The automated acceptance testing is a huge improvement as well from
the developer as the business viewpoint.
The team, product owner and business have insight on the testing
results and developers now immediatly which code is impacted/broken
when new functionality is added or existing functionality is changed.
As well the unit testing, as automated testing and nightly builds
greatly improve the stability of the environment, especially because
we have a lot of dependencies to third-party services. The application
integrates with a document management system, third party web
services, external data sources, ...
Kind regards,
Nathalie
Andrejus Baranovskis
Sep 25, 2009, 3:48:26 AM9/25/09
to adf-met...@googlegroups.com
Hi Florin,
--
Oracle ACE Director
My Blog - http://andrejusb.blogspot.com/
My JDev/ADF Samples list - http://andrejusb-samples.blogspot.com/
From my practice, Selenium script recording with ADF Faces Rich Client works on relatively basic level. Recently we have tried to test latest Selenium script recording version (1.0.2) with ADF 11g R1 and our results:
1) Doesn't work for menu/buttons navigation - opens pages randomly, not based on recorded script
2) CRUD test recording in Form component was successful
3) CRUD test recording in Table component failed completely - Selenium can't put data into columns
4) Doesn't work with Query Criteria
5) Doesn't work for LOV components
Ok, may be it will work when coding Selenium scripts manually, but then it will be too costly.
Regards,
--
Oracle ACE Director
My Blog - http://andrejusb.blogspot.com/
My JDev/ADF Samples list - http://andrejusb-samples.blogspot.com/
Jan Vervecken
Sep 25, 2009, 4:05:38 AM9/25/09
to ADF Enterprise Methodology Group
Thanks for the interresting feedback Andrejus.
Which tools does Oracle suggest for this kind of automated (Selenium
like) integration testing for ADF Faces Rich Client?
regards
Jan Vervecken
Which tools does Oracle suggest for this kind of automated (Selenium
like) integration testing for ADF Faces Rich Client?
regards
Jan Vervecken
Michael Koniotiakis
Oct 7, 2009, 1:43:32 PM10/7/09
to ADF Enterprise Methodology Group
I feel that Jdeveloper and Fusion Applications have a great Luck of
testing tools.
I think that TDD is not applicable because Fusion application
development with jdeveloper is declarative development and not java
coding
Most of the functionality is applyed without writing any java code.
You can't expect these developers to write thousants of lines of java
unit tests, to test that functionality.
thats why people are looking for (Selenium like) tools.
I think jdeveloper could have these kind of tools to declaratevly or
automaticaly test the functionality.
For example Application module browser is great for testing BC, but it
is manual.
I think a unit test generator of application module could be created
to declaratively configure and automaticaly test BC logic.
testing tools.
I think that TDD is not applicable because Fusion application
development with jdeveloper is declarative development and not java
coding
Most of the functionality is applyed without writing any java code.
You can't expect these developers to write thousants of lines of java
unit tests, to test that functionality.
thats why people are looking for (Selenium like) tools.
I think jdeveloper could have these kind of tools to declaratevly or
automaticaly test the functionality.
For example Application module browser is great for testing BC, but it
is manual.
I think a unit test generator of application module could be created
to declaratively configure and automaticaly test BC logic.
Andrejus Baranovskis
Oct 7, 2009, 2:57:15 PM10/7/09
to adf-met...@googlegroups.com
Hi Michael,
You can generate JUnit for Application Module already, with JUnit extension.
Michael Koniotiakis
Oct 7, 2009, 4:26:05 PM10/7/09
to ADF Enterprise Methodology Group
Hey Andrejus
Yes, You can generate JUnit for Application Module already, with JUnit
extension
And it creates a test class for each view object.
But the only test it does is that the view object is accessible, which
ofcourse never fail:
@Test
public void testAccess() {
ViewObject view = fixture1.getApplicationModule
().findViewObject("DepartmentsView1");
assertNotNull(view);
}
What i mean is that it could generate test cases for all operations
that can be done manualy in application module browser
i.e for each view object that you can Insert, update, delete data (if
updatable) and query data
it could thest associations and view links
It could test validations
It could even test custom created and exposed methods.
Imagine how much code is needed to test all that basic functionality
by writing methods in each each view object test class.
For each view object you would need 1 hour to create it and 10 hours
to write the test cases.
Anybody realy do that?
On Oct 7, 8:57 pm, Andrejus Baranovskis
> My Blog -http://andrejusb.blogspot.com/
> My JDev/ADF Samples list -http://andrejusb-samples.blogspot.com/- Hide quoted text -
Yes, You can generate JUnit for Application Module already, with JUnit
extension
And it creates a test class for each view object.
But the only test it does is that the view object is accessible, which
ofcourse never fail:
@Test
public void testAccess() {
ViewObject view = fixture1.getApplicationModule
().findViewObject("DepartmentsView1");
assertNotNull(view);
}
What i mean is that it could generate test cases for all operations
that can be done manualy in application module browser
i.e for each view object that you can Insert, update, delete data (if
updatable) and query data
it could thest associations and view links
It could test validations
It could even test custom created and exposed methods.
Imagine how much code is needed to test all that basic functionality
by writing methods in each each view object test class.
For each view object you would need 1 hour to create it and 10 hours
to write the test cases.
Anybody realy do that?
On Oct 7, 8:57 pm, Andrejus Baranovskis
> My JDev/ADF Samples list -http://andrejusb-samples.blogspot.com/- Hide quoted text -
Andrejus Baranovskis
Oct 8, 2009, 2:38:11 AM10/8/09
to adf-met...@googlegroups.com
Hi Michael,
My Blog - http://andrejusb.blogspot.com/
I agree with your point about Java coding. But, at the same time its not a big deal for Java developer to code JUnit. Even if you spend 10 hours, its still better comparing to 1 month bug fixing, without JUnit ;)
Michael Koniotiakis
Oct 14, 2009, 5:56:56 AM10/14/09
to ADF Enterprise Methodology Group
I downloaded, installed and tested Oracle Application Testing Suite
http://www.oracle.com/technology/software/products/app-testing/index.html
I easilly recorded a functional test directly to the deployed ADF
application.
It worked fine for LOVs, popups and buttons
First look seems to be great.
Anyone is using it?
On 8 Οκτ, 09:38, Andrejus Baranovskis <andrejus.baranovs...@gmail.com>
> My JDev/ADF Samples list -http://andrejusb-samples.blogspot.com/- Απόκρυψη κειμένου σε παράθεση -
>
> - Εμφάνιση κειμένου σε παράθεση -
http://www.oracle.com/technology/software/products/app-testing/index.html
I easilly recorded a functional test directly to the deployed ADF
application.
It worked fine for LOVs, popups and buttons
First look seems to be great.
Anyone is using it?
On 8 Οκτ, 09:38, Andrejus Baranovskis <andrejus.baranovs...@gmail.com>
>
> - Εμφάνιση κειμένου σε παράθεση -
Simon Haslam
Oct 14, 2009, 12:12:20 PM10/14/09
to ADF Enterprise Methodology Group
No, not yet. Last year I did some load tests on SRDemo 10.1.3 to try
to better understand passivation characteristics but I used The
Grinder (http://grinder.sourceforge.net/ - maintained by Phil Aston, a
really top notch WebLogic guy based in the UK). The Grinder is very
flexible (much more so than Apache JMeter IMO) but non-trivial to get
started with.
Thanks for the tip Michael - it sounds worth a investigating!
Simon
On Oct 14, 10:56 am, Michael Koniotiakis <mko...@hotmail.com> wrote:
> I downloaded, installed and tested Oracle Application Testing Suitehttp://www.oracle.com/technology/software/products/app-testing/index....
> > My JDev/ADF Samples list -http://andrejusb-samples.blogspot.com/-Απόκρυψη κειμένου σε παράθεση -
to better understand passivation characteristics but I used The
Grinder (http://grinder.sourceforge.net/ - maintained by Phil Aston, a
really top notch WebLogic guy based in the UK). The Grinder is very
flexible (much more so than Apache JMeter IMO) but non-trivial to get
started with.
Thanks for the tip Michael - it sounds worth a investigating!
Simon
On Oct 14, 10:56 am, Michael Koniotiakis <mko...@hotmail.com> wrote:
> I downloaded, installed and tested Oracle Application Testing Suitehttp://www.oracle.com/technology/software/products/app-testing/index....
Reply all
Reply to author
Forward
0 new messages