Random JUnit Test

The most any of my rambling over at Stack Overflow has inspired thus far is a blog post. But one post has inspired some one else to create the Random jUnit Executor.  If you suspect that some of your tests are dropping a little bit of state behind, this lovely little tool might help you descovery it.

Finding foreign keys on an Oracle database

If you create your tables with foreign key constraints you can query the all_constraints table using the query below.

select owner, constraint_name, constraint_type,

       table_name, r_owner, r_constraint_name

 from all_constraints

where constraint_type='R'

  and r_constraint_name in  

                (

                 select constraint_name

                   from all_constraints

                  where constraint_type in ('P','U')

                    and table_name='TABLE NAME'

                 );

However not all of us have such luck. The other option, if your naming structure allows, is to search for foreign keys by querying column names in the user_tab_columns. At my current workplace we use two different naming standards but both make it easy to find foreign keys. The first is the use of FK_TABLE_NAME_ID for foreign keys. So to find the foreign keys we can use the query below.

select table_name, column_name 

  from user_tab_columns
 where column_name like 'FK_AGREEMENT_ID'

The second naming structure in use is were we prefix each column with a TLA for the name and name keys with a _LKEY suffix. So to find all customer (CST) foreign keys we can use

select table_name, column_name 

  from user_tab_columns
 where column_name like '%_CST_LKEY'

Happy New Year.

Defining unit and integration

I've a rough form of this post boiling away at the back of my noggin for a little while but a post on StackOverflow and an old blog post by Roy Osherove has prompted me to finally write it.

While this goes against a previous post on this subject, I think Roy has hit the nail on the head with his definition of "unit test". Integration tests I have an issue with, but mostly as I think the bucket "integration test" is too large.

I see two types of integration tests:

Unigration Tests: Tests written as unit tests, but as a key part of what they do they hits one external resource which is under complete control of the developer. A unigration test is a fast (as it can be), consistent (with early failure with Inconclusive if the external resource does not exist), automated and repeatable test of a functional unit-of-work in the system. For example testing the individual methods in data access layer.
This differs from Roy's "integration test" in that he does not specify functional unit-of-work in the system and he allows for inconsistent tests, where as for a unigration test only allows for three states, Passed, Failed and Resource Unavailable (Inconclusive).

Pure Integration Tests: Is any test which does not fall into the above two definitions. Either as the developer does not have full control over the resource, is testing more than a single functional unit of work or requires multiple external resources.