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?
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.
> 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?
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
On Fri, Sep 18, 2009 at 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.
>> 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?
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?
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.
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.
On Sep 19, 8:35 pm, ugb <ulrich.gerkmannbart...@googlemail.com> wrote:
> 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.
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.
> > 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?
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
On Sep 19, 7:35 pm, ugb <ulrich.gerkmannbart...@googlemail.com> wrote:
> 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.
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
On Sep 20, 7:30 pm, "florin.marcus" <florin.mar...@gmail.com> wrote:
> 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.
> On Sep 19, 8:35 pm, ugb <ulrich.gerkmannbart...@googlemail.com> wrote:
> > 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.
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 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
> On Sep 20, 7:30 pm, "florin.marcus" <florin.mar...@gmail.com> wrote:
> > 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.
> > On Sep 19, 8:35 pm, ugb <ulrich.gerkmannbart...@googlemail.com> wrote:
> > > 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.
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
On Sep 22, 8:01 pm, Florin Marcus <florin.mar...@gmail.com> wrote:
> 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
> > 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
> > On Sep 20, 7:30 pm, "florin.marcus" <florin.mar...@gmail.com> wrote:
> > > 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.
> > > > 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.
Hi Florin,
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.
> 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
> > 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
> > On Sep 20, 7:30 pm, "florin.marcus" <florin.mar...@gmail.com> wrote:
> > > 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 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.
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.
On 18 Σεπτ, 10:40, Nathalie Roman <liekero...@gmail.com> wrote:
> 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?
> 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.
> On 18 Σεπτ, 10:40, Nathalie Roman <liekero...@gmail.com> wrote:
> > 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?
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.
<andrejus.baranovs...@gmail.com> wrote:
> Hi Michael,
> You can generate JUnit for Application Module already, with JUnit extension.
> Andrejus
> 2009/10/7 Michael Koniotiakis <mko...@hotmail.com>
> > 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.
> > On 18 Σεπτ, 10:40, Nathalie Roman <liekero...@gmail.com> wrote:
> > > 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?
Hi Michael,
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 ;)
Andrejus
2009/10/7 Michael Koniotiakis <mko...@hotmail.com>
> 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
> <andrejus.baranovs...@gmail.com> wrote:
> > Hi Michael,
> > You can generate JUnit for Application Module already, with JUnit
> extension.
> > Andrejus
> > 2009/10/7 Michael Koniotiakis <mko...@hotmail.com>
> > > 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.
> > > On 18 Σεπτ, 10:40, Nathalie Roman <liekero...@gmail.com> wrote:
> > > > 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?
> Hi Michael,
> 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 ;)
> Andrejus
> 2009/10/7 Michael Koniotiakis <mko...@hotmail.com>
> > 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
> > <andrejus.baranovs...@gmail.com> wrote:
> > > Hi Michael,
> > > You can generate JUnit for Application Module already, with JUnit
> > extension.
> > > Andrejus
> > > 2009/10/7 Michael Koniotiakis <mko...@hotmail.com>
> > > > 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.
> > > > On 18 Σεπτ, 10:40, Nathalie Roman <liekero...@gmail.com> wrote:
> > > > > 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?
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 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>
> wrote:
> > Hi Michael,
> > 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 ;)
> > Andrejus
> > 2009/10/7 Michael Koniotiakis <mko...@hotmail.com>
> > > 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
> > > <andrejus.baranovs...@gmail.com> wrote:
> > > > Hi Michael,
> > > > You can generate JUnit for Application Module already, with JUnit
> > > extension.
> > > > Andrejus
> > > > 2009/10/7 Michael Koniotiakis <mko...@hotmail.com>
> > > > > 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.
> > > > > On 18 Σεπτ, 10:40, Nathalie Roman <liekero...@gmail.com> wrote:
> > > > > > 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?
