I have had a quick glance a the utPLSQL code.
It's quite hard to read and follow as there are multipe cross package dependencies.
Procedures and functions don't seem to follow SOLID design pronciples. Specially the single responsibility principle.
Anyway. I was cosidering cotribution to the code, however the effort needed to know how things work plus lack of automated tests for existing functionality are a bit discourageing.
I wonder. That's a bold thought though. Is it worth to invest in test coverage for utPLSQL plus time to refactor, rework, remove some features? Would it be better/simplier to start form a clean slate for Oracle 11+ with knowledge of existing valuable features and difficulties with some of them?
Last edit: Jacek Gebal 2015-09-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Paul,
Sorry for misspellings in my previous comment. It happens to me when I'm rushing to write my thoughts. What I had in mind is that code, though modularised is too tightly coupled and functions/procedures are tightly coupled in most of the cases.
The [SOLID](https://en.wikipedia.org/wiki/SOLID_(object-oriented_design) is a set of rules that greatly improve code readability and maintainability, though it's adessed to Object Oriented Programming many of it's values can be used in SQL and PL/SQL
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have done extensive work with SQL Developer Unit Test. Much of it is posted at www.reldesgen.com. More recently, I have been supporting utPLSQL unit testing. We had a great deal of trouble getting JUnit reports to Jenkins from utPLSQL, so I wrote a custom JUnit report (using my employer's dollar, so I am not able to share.). While researching the utPLSQL repository for that effort, I found it to be very messy. Given some of the problems I have had with both SQL Developer and utPLSQL, I am creating requirements and designs for a streamlined unit testing software that is compatable with utPLSQL. This streamlining will go back to the roots of JUnit and it's simplicity. Before I get too far along, I wanted to introduce the idea to this group. If there is a desire to incorporate this effort into the utPLSQL project, I am open. Target set, begin throwing darts. :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think I did about the same thing for Bamboos Junit Test reader and I'd echo your feelings (it seems there's a lot of legacy code in the project which makes it quite difficult to understand). Cleaned up version would be nice - with some additional roadsigns to help expand the functionality (add some iterators etc).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I totally agree with you. I think there is a lot of improvements possible for utPlsql which shouldn't be to hard, but the code is really hard to read, and has too much code smells to change things. Also the lack technical documentation doesn't help much. This kept me from contributing so far (and the fact that I am not familiar sith svn, but that is another topic).
I think the interface of utPLSQL is not that baf. The methods and packages that are called are really straightforward and clean, so changing the backend into something better has my preference over starting something new.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I fully agree with these sentiments. Here's what I'm thinking...
I'm going to be moving utPLSQL to GitHub shortly - several people have asked for that, and while there might be a few teething issues during the transition (and defnitely a learning curve for me!), I think it will be beneficial in the long run. I'll try to get this completed in January.
I'm thinking we take that opportunity to start work on a cleaned up v3. I don't really want to delete everything and start from scratch, but I fully agree that there's a lot of room to improve things. For a start, there's a whole load of code that uses a bespoke conditional commenting technique to provide compatibility with old versions of Oracle. I think this could pretty much all be removed now.
One thing I'd like to do is thoroughly add/standardise code comments. I've used NaturalDocs in the past. It generates quite nice HTML pages from easy-to-read comments, but I'm open to other suggestions.
Does anyone have any thoughts about how we can best plan our efforts or design what the new version will look like?
Thanks,
Paul
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am close to a first draft of a proposal for the v3 cleanup. The main idea is to aggressively streamline the basic utPSQL functionality and split-off other aspects into separate projects. Once those projects are seeded, the organic growth of all the projects should increase because of better focus and simpler code in each project. Currently, I would like to propose these projects:
utPLSQL Core v3 of the current utPSQL project. The install is reduced to 3 (new) tables and 2 packages (1 new and 1 to replace UTASSERT/UTASSERT2).
Legacy Repository Add-on This add-on will load unit test data from utPLSQL v3 data structures to the latest v2 repository.
Automatic Source Recompile Add-on This add-on will perform the automatic recompile from a database file system directory.
Report Generator Add-on This add-on will perform the custom reporting currently supported in utPLSQL. It will require the Legacy Repository Add-on.
Test Package Generator Add-on This add-on will generate test skeletons for use as a starting point for a unit test package.
Structure Comparison Generator Add-on This add-on is Dan Spencer's contribution that creates functions for the comparison of record types.
Jenkins JUnit XML Add-on This add-on generates JUnit XML files compatible with Jenkins from the unit test data of the last TestSuite execution.
Historical Test Data Storage As each test suite completes, this add-on captures the test data for historical storage in a streamlined repository, making ad-hoc report generation much easier.
I am still reviewing the details of the proposal. My biggest concern is Feuerstein's approval. He carries a lot of weight in our industry.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, I'm not as close as I thought. As I was categorizing all the packages, I found quite a bit of undocumented v2 functionality that is only mentioned in bits and peices in the release notes. It looks like the overall goal is sound. I just need a little longer to survey and document the proposed changes.
It would be helpful to review a major streamlining concept in in the proposal. The concept is PLSQL package driven test configuration. TestSuites and TestCases will be configured via a user written test runner package that makes utPSQL calls. No required “prefixes” on procedure or package names. No required setup or teardown procedures. No pre-setup of TestSuite/TestCase configuration in the database. With the add-ons listed above, and a few legacy "hooks", I should be able to demonstrate a simple conversion of existing v1/v2 utPLSQL tests to v3.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have had a quick glance a the utPLSQL code.
It's quite hard to read and follow as there are multipe cross package dependencies.
Procedures and functions don't seem to follow SOLID design pronciples. Specially the single responsibility principle.
Anyway. I was cosidering cotribution to the code, however the effort needed to know how things work plus lack of automated tests for existing functionality are a bit discourageing.
I wonder. That's a bold thought though.
Is it worth to invest in test coverage for utPLSQL plus time to refactor, rework, remove some features?
Would it be better/simplier to start form a clean slate for Oracle 11+ with knowledge of existing valuable features and difficulties with some of them?
Last edit: Jacek Gebal 2015-09-06
I see where you're coming from, but personally, I don't really want to restart the project from scratch.
I'm not familiar with the term "SOLIT design principles" - would you mind elaborating on this?
Hi Paul,
Sorry for misspellings in my previous comment. It happens to me when I'm rushing to write my thoughts. What I had in mind is that code, though modularised is too tightly coupled and functions/procedures are tightly coupled in most of the cases.
The [SOLID](https://en.wikipedia.org/wiki/SOLID_(object-oriented_design) is a set of rules that greatly improve code readability and maintainability, though it's adessed to Object Oriented Programming many of it's values can be used in SQL and PL/SQL
I have done extensive work with SQL Developer Unit Test. Much of it is posted at www.reldesgen.com. More recently, I have been supporting utPLSQL unit testing. We had a great deal of trouble getting JUnit reports to Jenkins from utPLSQL, so I wrote a custom JUnit report (using my employer's dollar, so I am not able to share.). While researching the utPLSQL repository for that effort, I found it to be very messy. Given some of the problems I have had with both SQL Developer and utPLSQL, I am creating requirements and designs for a streamlined unit testing software that is compatable with utPLSQL. This streamlining will go back to the roots of JUnit and it's simplicity. Before I get too far along, I wanted to introduce the idea to this group. If there is a desire to incorporate this effort into the utPLSQL project, I am open. Target set, begin throwing darts. :-)
I think I did about the same thing for Bamboos Junit Test reader and I'd echo your feelings (it seems there's a lot of legacy code in the project which makes it quite difficult to understand). Cleaned up version would be nice - with some additional roadsigns to help expand the functionality (add some iterators etc).
Hi Jacek,
I totally agree with you. I think there is a lot of improvements possible for utPlsql which shouldn't be to hard, but the code is really hard to read, and has too much code smells to change things. Also the lack technical documentation doesn't help much. This kept me from contributing so far (and the fact that I am not familiar sith svn, but that is another topic).
I think the interface of utPLSQL is not that baf. The methods and packages that are called are really straightforward and clean, so changing the backend into something better has my preference over starting something new.
Hi guys,
I fully agree with these sentiments. Here's what I'm thinking...
I'm going to be moving utPLSQL to GitHub shortly - several people have asked for that, and while there might be a few teething issues during the transition (and defnitely a learning curve for me!), I think it will be beneficial in the long run. I'll try to get this completed in January.
I'm thinking we take that opportunity to start work on a cleaned up v3. I don't really want to delete everything and start from scratch, but I fully agree that there's a lot of room to improve things. For a start, there's a whole load of code that uses a bespoke conditional commenting technique to provide compatibility with old versions of Oracle. I think this could pretty much all be removed now.
One thing I'd like to do is thoroughly add/standardise code comments. I've used NaturalDocs in the past. It generates quite nice HTML pages from easy-to-read comments, but I'm open to other suggestions.
Does anyone have any thoughts about how we can best plan our efforts or design what the new version will look like?
Thanks,
Paul
Paul,
I am close to a first draft of a proposal for the v3 cleanup. The main idea is to aggressively streamline the basic utPSQL functionality and split-off other aspects into separate projects. Once those projects are seeded, the organic growth of all the projects should increase because of better focus and simpler code in each project. Currently, I would like to propose these projects:
I am still reviewing the details of the proposal. My biggest concern is Feuerstein's approval. He carries a lot of weight in our industry.
Hi Duane, I'll be interested to see what you come up with. Thanks for putting the time into it :)
Well, I'm not as close as I thought. As I was categorizing all the packages, I found quite a bit of undocumented v2 functionality that is only mentioned in bits and peices in the release notes. It looks like the overall goal is sound. I just need a little longer to survey and document the proposed changes.
It would be helpful to review a major streamlining concept in in the proposal. The concept is PLSQL package driven test configuration. TestSuites and TestCases will be configured via a user written test runner package that makes utPSQL calls. No required “prefixes” on procedure or package names. No required setup or teardown procedures. No pre-setup of TestSuite/TestCase configuration in the database. With the add-ons listed above, and a few legacy "hooks", I should be able to demonstrate a simple conversion of existing v1/v2 utPLSQL tests to v3.