Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

prohuddle-utPLSQL v3 - Ultimate unit testing framework for Oracle

1.373 Aufrufe

Veröffentlicht am

Fundamentals of Unit Testing and TDD as a practice and presentation of core features available with utPLSQL v3.
Unit testing for Oracle Databases and PLSQL programming language.

Veröffentlicht in: Software
  • Als Erste(r) kommentieren

prohuddle-utPLSQL v3 - Ultimate unit testing framework for Oracle

  1. 1. utPLSQL v3 Ultimate Unit Testing framework for Oracle Jacek Gębal twitter: @GebalJacek mail: jgebal@gmail.com blog: oraclethoughts.com Principal Data Engineer Developer @Fidelity Investments - Ireland co-author of: utPLSQL v3
  2. 2. Plan ● Oracle Database testing tools ● utPLSQL v3 ● Rules of unit testing ● Test Driven Development with utPLSQL ● Testing data ● Test run options ● Suites ● utPLSQL - SQL Developer extension ● utPLSQL-cli - running tests from command line ● CI/CD integration
  3. 3. Steven Feuerstein 1999 PLUTO PL/Unit ruby-plsql-spec DBFit Oracle Database Unit Testing market
  4. 4. Market expectations
  5. 5. The team ● Jacek Gębal ● Pavel Kaplya ● Robert Love ● David Pyke ● Vinicius Avellar ● Samuel Nitsche ● Philipp Salvisberg
  6. 6. Why utPLSQL v3 ? ● free ● open source ● pure PL/SQL ● Tested on 11gR2 - 12cR2 ● IDE independent ● database independent ● CI/CD oriented ● modular and extendable
  7. 7. Properties of Unit Tests ● Fast ● Isolated ● Repeatable ● Self-verifying ● Thorough & Timely https://github.com/.../F.I.R.S.T-Principles-of-Unit-Testing https://pragprog.com/.../2012-01/unit-tests-are-first
  8. 8. The Unit Test also needs to be ● Simple ● Automated ● Testing one behavior ● Living documentation ● Developer’s responsibility
  9. 9. Delivering software that is: ● Safe to change ● Maintainable ● Can be tested and delivered iteratively Why should I care ?
  10. 10. What to test in database ? ● Behavior ○ Logic ○ in / out structure ○ State (?) ● Avoid ○ under-testing ○ over-testing ○ meaningless tests ○ flaky tests ○ aiming for metrics (coverage/test count)
  11. 11. Test Driven Development ● write a test ● make it fail ● keep it simple ● tests are examples ● tests become documentation ● get to green fast ● take baby steps ● stuck? undo and start over ● write only enough code to pass the test ● remove duplication (in code and tests) ● rename and clean up ● run tests and stay green ● change implementation, not behavior ● improve structure in small steps RED GREEN REFACTOR With TDD you get: ● Fast feedback loop ● Visible progress ● Code is tested before it exists ● Accomplishment with every new test
  12. 12. Test Driven Development with utPLSQL v3 ● suite structure ● annotations ● expectation syntax ● running tests ● failure and error messages
  13. 13. demo
  14. 14. Summary Annotation syntax: --%name( parameter[s] ) Example: --%suite(description) --%test(description) Expectation examples: ut.expect( 1 ).to_( equal( 1 ) ); ut.expect( ‘Chuck’ ).to_equal( ‘Chuck’ ); Running tests: exec ut.run();
  15. 15. Annotations Package: ● --%suite(<description>) ● --%suitepath(<path>) ● --%rollback(auto/manual) ● --%disabled Test procedure: ● --%test(<description>) ● --%throws(<error_No>[,...]) ● --%beforetest(<proc_name>) ● --%aftertest(<proc_name>) ● --%rollback(auto/manual) ● --%disabled Procedure: ● --%beforeall, --%afterall ● --%beforeeach, --%aftereach
  16. 16. Expectations & matchers ● be_null ● be_true ● be_greater_than( expected ) ● be_less_than( expected ) ● equal( expected ) ● be_like( mask [, escape_char] ) ut.expect( actual ).to_( matcher(param[, param...]) ); ut.expect( actual ).not_to( matcher(param[, param...]) ); ● be_not_null ● be_false ● be_greater_or_equal( expected ) ● be_less_or_equal( expected ) ● be_between( lower, upper ) ● match( pattern [, modifiers] ) ● be_empty ● have_count( count ) Matchers:
  17. 17. Equality rules in tests ut.expect( 100 ).to_equal( ‘100’ ); ut.expect( ‘abcdef’ ).to_equal( to_clob( ‘abcdef’ ) ); ut.expect( systimestamp ).to_equal( current_timestamp ); ut.expect( sysdate ).to_equal( ‘20-MAR-2018’ ); When it comes to unit testing ... Data types matter!
  18. 18. Supported data-types ● clob, blob ● timestamp (with (local) timezone) ● interval (day to second / year to month) ● cursor ● object, nested table, varray type ● number (integer) ● varchar2 (char / varchar) ● date ● boolean
  19. 19. Testing data ● data setup / cleanup ● cursor data comparison ● automatic rollback ● selective comparison
  20. 20. demo
  21. 21. --%suite(Demo suite) --%beforeall procedure data_setup_before_all; --%beforeeach procedure thing_to_do_before_each_test; --%test(Does a thing) procedure test_the_thing; --%test(Does stuff) --%beforetest(setup_before_stuff) --%aftertest(cleanup_after_stuff) procedure test_stuff; procedure setup_before_stuff; procedure cleanup_after_stuff; --%afterall procedure cleanup_after_all_is_done; data_setup_before_all thing_to_do_before_each_test test_the_thing thing_to_do_before_each_test setup_before_stuff test_stuff cleanup_after_stuff cleanup_after_all_is_done savepoint before_suite Order of execution savepoint before_test rollback to before_suite rollback to before_test savepoint before_test rollback to before_test & test isolation
  22. 22. Organizing tests ● suites hierarchy with suitepath ● parent, siblings, ancestors ● shared beforeall / afterall ● suites isolation / setup scope
  23. 23. demo
  24. 24. package test_add_room_content as --%suite(Add content to a room) --%suitepath(org.utplsql.demo.test_rooms) package test_remove_rooms_by_name as --%suite(Remove rooms by name) --%suitepath(org.utplsql.demo.test_rooms) package test_rooms as --%suite --%suitepath(org.utplsql.demo) package test_betwnstr as --%suite(description) savepoint rollback to savepoint Suite hierarchy test run utplsql test_betwnstr test_rooms test_add_room_content test_remove_rooms_by_name org demo savepoint rollback to savepoint savepoint rollback to savepoint
  25. 25. Test run options ● default options ● single schema ● single package ● single test ● suite ● multiple schema ● specifying reporter
  26. 26. demo
  27. 27. utPLSQL - SQL Developer extension
  28. 28. demo
  29. 29. utplsql-cli ● Windows/Linux/Mac ● real-time reporting ● multi-reporting ● Oracle client independent ● CI/CD oriented
  30. 30. demo
  31. 31. Integration ● CI/CD servers ○ Jenkins ○ TeamCity ○ Travis ○ other... ● Sonar ○ generic test results ○ code coverage ● Coveralls ○ code coverage
  32. 32. demo
  33. 33. utPLSQL v3 recap ● free, open-source, pure PL/SQL ● annotations ● human readable syntax ● data type - aware comparison ● automatic test isolation ● rich selection of matchers ● supports cursors, object types, nested tables ● CI/CD oriented ● code coverage
  34. 34. Resources Cheat-sheet: https://www.cheatography.com/jgebal/cheat-sheets/utplsql-v3/ Documentation: http://utplsql.org/utPLSQL/ Source code: https://github.com/utPLSQL/utPLSQL Releases: https://github.com/utPLSQL/utPLSQL/releases utPLSQL-cli: https://github.com/utPLSQL/utPLSQL-cli/releases SQLDeveloper-extension: https://github.com/utPLSQL/utPLSQL-SQLDeveloper/releases Twitter: @utplsql Demo project: https://github.com/utPLSQL/utPLSQL-demo-project Sonar results: https://sonarcloud.io/dashboard?id=utPLSQL Coveralls results: https://coveralls.io/github/utPLSQL/utPLSQL Travis-CI builds: https://travis-ci.org/utPLSQL/utPLSQL

×