Saturday, 25 June 2011
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.
Labels:
cool,
junit,
random,
stack overflow
Thursday, 6 January 2011
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.
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.
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 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'
);
select table_name, column_name
from user_tab_columns
where column_name like 'FK_AGREEMENT_ID'
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'
where column_name like '%_CST_LKEY'
Happy New Year.
Wednesday, 24 November 2010
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.
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.
Labels:
integration tests,
Unigration Tests,
unit testing
Subscribe to:
Posts (Atom)
