• Save
Automated Unit Testing
Upcoming SlideShare
Loading in...5
×
 

Automated Unit Testing

on

  • 1,338 views

 

Statistics

Views

Total Views
1,338
Views on SlideShare
1,338
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Introduction Introduce yourself Presentation about unit testing in an APEX dev project Presentation focusses on the development process during an APEX project
  • Various forms of testing, all with there own charicteristcs and methods. The basis and fundament of the application is tested/verified by unit tests, done by the developer (peer reviews etc.) Without this basis, the application will be build on a weak fundament. Since the above mentioned tests have another focus and purpose. Stress Test – Real Application Testing
  • Unit testing in a Oracle environment is tricky and therefor not done automatically . Most units are highly data dependent. Making it harder to isolate certain testcases and scenarios From the most used development tooling there is no open standard unit test method, like Java has Junit, which is available (with plugins) in most IDEs
  • When looking in projects I have worked with, I see many problems when unit / system testing is being done - the created tests are not repeated, once it works it is done and no pro active retesting is done in case the software is changed - Mostly the tests are performed manually, mostly because of the high data dependent, and the developer has to validate if the outcome is confirm the expected result. - The test cases that are being tested are limited, it is hard to estimate if the tests cover all behavior of the unit Unit testing must be part of the developmentprocess
  • Sogeti Nederland B.V.
  • Sogeti Nederland B.V. So why we want to atomate this part of the development process - repeatable test cases and unit tests saves time - Reporting is possible, telling about how many test cases are ran and what the code coverage is of the unittests
  • Sogeti Nederland B.V. SQLDevloper now has a full PL SQL unit test framework This framework was introduced in SQLDev 2.2 and expanded in 3.0 Framework consist of different components, tests are the unittests , and with suites you are able to combine testcases Libaries and lookups can be used to fulfill the pre and post conditions of the unit In the startup and teardown actions you can code the preconditions, eg. Create d=the data the test case is dependent on With validations the framework can validate the outcome of the unit test automatically
  • Why is this suitable to use in an APEX project - best practice is to implement complex login in PL?SQL packages on the database - We tried to avoid tight coupling with APED, see direct reference item values or collections - within SQLDev 3.0 the framework has some great new features, for example the supports custom data types and Test synchronization. which makes it more usable
  • http://www.whitehorses.nl/whitebooks/2010/unittesten-sql-developer

Automated Unit Testing Automated Unit Testing Presentation Transcript

  • In an APEX development project Automated unit testing Simon Boorsma Senior Technology Specialist Oracle at Sogeti Netherlands
  • Various forms of testing
    • User or acceptance test
    • Test by (key)end users
    • Functional and regression test
    • Test of the functionality by test engineers
    • Stress and performance test
    • Validation technical aspects of the application by DBAs or SAs
    • Unit test
    • A unit is being validated by a developer
    • Without unit testing a weak fundament
  • Unit testing - Problems
    • Data dependent behavior
      • Content of tables, cursor variables and parameters
    • No open standard test method
      • From the community and the development tools
    • Coding is more fun than testing
      • Developers opinion
    • Time consuming
  • Unit testing – In practice
    • Unit tests not repeated
    • When it works, no pro active repeating reviews
    • Limited testcases
    • code and behavior coverage of the test cases is unclear
    • Manual review
    • Review errors can be made
    • Unit tests starts after coding
    • Pursuit for positive result
    • Many bugs during testing causes a loose of focus
  • Unit testing – Test Driven Development
    • Know the expected behavior
    • Specify interface carefully
    • Define test cases
    • Sufficient code and behavior coverage?
    • Implement the unit
    • Code to fulfill the test cases
    • Specify behavior before start coding
  • Automated unit testing
    • Repeatable unit test cases
    • Expandable
    • Automatic review
    • Report possibilies
    • Run unit tests with just hitting the play button
  • PL/SQL unit test framework
    • Tests and suites
    • Libraries and Lookups
    • Startup and Teardown actions
    • Validations
    • Reports
  • Demonstration
  • Use in APEX project
    • Logic implemented in PL/SQL packages
      • Validations and Processes
    • No tight coupling with APEX
      • No use of v(‘ITEM’)
    • Support for custom data types
  • staat voor resultaat
  • Features SQLDeveloper 3.0
    • Test synchronization
    • Advanced Data types support