Overview | Package | Class | Use | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

## org.hibernate.testing.junit.functional
Class FunctionalTestCase

    java.lang.Object
      junit.framework.Assert
          junit.framework.TestCase
              org.hibernate.testing.junit.UnitTestCase
                  org.hibernate.testing.junit.functional.FunctionalTestCase

All Implemented Interfaces:
  junit.framework.Test, ExecutionEnvironment.Settings

Direct Known Subclasses:
  BaseCacheTestCase, DatabaseSpecificFunctionalTestCase

    public abstract class FunctionalTestCase

extends UnitTestCase
implements ExecutionEnvironment.Settings

Most of the Hibernate test suite in fact is a series of functional tests, not unit tests. Here is a base class for these functional tests.

Author:
  Steve Ebersole

Field Summary
`static Class[]` | `NO_CLASSES`
`static String[]` | `NO_MAPPINGS`

Constructor Summary
`FunctionalTestCase(String string)`

Method Summary
`void` | `afterConfigurationBuilt(Mappings mappings, Dialect dialect)`
`void` | `afterSessionFactoryBuilt(SessionFactoryImplementor sfi)`
`protected boolean` | `allowsPhysicalColumnNameInHaving(String testDescription)` Does the db/dialect support using a column's physical name in the having clause even after it has been aliased in the select/group-by clause.
`protected boolean` | `allowsPhysicalColumnNameInOrderby(String testDescription)` Does the db/dialect support using a column's physical name in the order-by clause even after it has been aliased in the select clause.
`boolean` | `appliesTo(Dialect dialect)` Intended to indicate that this test class as a whole is intended for a dialect or series of dialects.
`protected void` | `assertAllDataRemoved()`
`protected void` | `cleanupTest()`
`void` | `configure(Configuration cfg)`
`boolean` | `createSchema()`
`protected boolean` | `dialectIs(Class dialectClass)`
`protected boolean` | `dialectIsCaseSensitive(String testDescription)` Is the db/dialect sensitive in terms of string comparisons?
`protected boolean` | `dialectIsNot(Class dialectClass)`
`protected boolean` | `dialectIsNot(Class[] dialectClasses)`
`protected boolean` | `dialectIsOneOf(Class[] dialectClasses)`
`protected boolean` | `dialectSupportsEmptyInList(String testDescription)` Does the db/dialect support empty lists in the IN operator? For example, is "...
`Class[]` | `getAnnotatedClasses()`
`String` | `getBaseForMappings()`
`String` | `getCacheConcurrencyStrategy()`
`protected Configuration` | `getCfg()`
`protected Dialect` | `getDialect()`
`ExecutionEnvironment` | `getEnvironment()`
`String[]` | `getMappings()`
`protected SessionFactory` | `getSessions()` Get the factory for this test environment.
`protected boolean` | `isSerializableIsolationEnforced()` Do connections enforce SERIALIZABLE isolation...
`Session` | `openSession()`
`Session` | `openSession(Interceptor interceptor)`
`boolean` | `overrideCacheStrategy()`
`protected void` | `prepareTest()`
`protected boolean` | `readCommittedIsolationMaintained(String scenario)` Is connection at least read committed? Not, that this skip check relies on the JDBC driver reporting the true isolation level correctly.
`boolean` | `recreateSchemaAfterFailure()`
`protected void` | `runTest()` runTest is overridden in order to apply session closure assertions.
`void` | `setEnvironment(ExecutionEnvironment environment)`
`protected void` | `setUp()` Override `TestCase.setUp()` to check if we need to build a locally managed execution environment.
`protected SessionFactoryImplementor` | `sfi()` Get the factory for this test environment, casted to `SessionFactoryImplementor`.
`protected void` | `skipExpectedFailure(Throwable error)`
`protected boolean` | `supportsCircularCascadeDelete()`
`protected boolean` | `supportsExpectedLobUsagePattern()` Expected LOB usage pattern is such that I can perform an insert via prepared statement with a parameter binding for a LOB value without crazy casting to JDBC driver implementation-specific classes...
`protected boolean` | `supportsLobValueChangePropogation()` Does the current dialect support propogating changes to LOB values back to the database? Talking about mutating the underlying value as opposed to supplying a new LOB instance...
`protected boolean` | `supportsResultSetPositionQueryMethodsOnForwardOnlyCursor()`
`protected boolean` | `supportsSubqueryOnMutatingTable()`
`protected boolean` | `supportsSubselectOnLeftSideIn()`
`protected boolean` | `supportsUnboundedLobLocatorMaterialization()` Is it supported to materialize a LOB locator outside the transaction in which it was created? Again, part of the trickiness here is the fact that this is largely driver dependent.
`protected void` | `tearDown()` Override `TestCase.tearDown()` to tear down the execution environment if it is locally managed.

Methods inherited from class org.hibernate.testing.junit.UnitTestCase
`assertClassAssignability, assertElementTypeAssignability, createFailureExpectedSuite, fullTestName, reportSkip, runBare`

Methods inherited from class junit.framework.TestCase
`countTestCases, createResult, getName, run, run, setName, toString`

Methods inherited from class junit.framework.Assert
`assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertEquals, assertFalse, assertFalse, assertNotNull, assertNotNull, assertNotSame, assertNotSame, assertNull, assertNull, assertSame, assertSame, assertTrue, assertTrue, fail, fail`

Methods inherited from class java.lang.Object
`clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait`

Field Detail

### NO_MAPPINGS

    public static final String[] NO_MAPPINGS

### NO_CLASSES

    public static final Class[] NO_CLASSES

Constructor Detail

### FunctionalTestCase

    public FunctionalTestCase(String string)

Method Detail

### getEnvironment

    public ExecutionEnvironment getEnvironment()

### setEnvironment

    public void setEnvironment(ExecutionEnvironment environment)

### prepareTest

    protected void prepareTest()
                        throws Exception

  Throws:
    `Exception`

### cleanupTest

    protected void cleanupTest()
                        throws Exception

  Throws:
    `Exception`

### setUp

    protected final void setUp()
                        throws Exception

  Override `TestCase.setUp()` to check if we need to build a locally managed execution environment.

  Overrides:
    `setUp` in class `junit.framework.TestCase`
  Throws:
    `Exception`

### tearDown

    protected final void tearDown()
                           throws Exception

  Override `TestCase.tearDown()` to tear down the execution environment if it is locally managed.

  Overrides:
    `tearDown` in class `junit.framework.TestCase`
  Throws:
    `Exception`

### runTest

    protected void runTest()
                    throws Throwable

  runTest is overridden in order to apply session closure assertions.

  Overrides:
    `runTest` in class `junit.framework.TestCase`
  Throws:
    `Throwable`

### assertAllDataRemoved

    protected void assertAllDataRemoved()

### skipExpectedFailure

    protected void skipExpectedFailure(Throwable error)

  Overrides:
    `skipExpectedFailure` in class `UnitTestCase`

### getMappings

    public String[] getMappings()

  Specified by:
    `getMappings` in interface `ExecutionEnvironment.Settings`

### getBaseForMappings

    public String getBaseForMappings()

  Specified by:
    `getBaseForMappings` in interface `ExecutionEnvironment.Settings`

### getAnnotatedClasses

    public Class[] getAnnotatedClasses()

  Specified by:
    `getAnnotatedClasses` in interface `ExecutionEnvironment.Settings`

### createSchema

    public boolean createSchema()

  Specified by:
    `createSchema` in interface `ExecutionEnvironment.Settings`

### recreateSchemaAfterFailure

    public boolean recreateSchemaAfterFailure()

  Specified by:
    `recreateSchemaAfterFailure` in interface `ExecutionEnvironment.Settings`

### configure

    public void configure(Configuration cfg)

  Specified by:
    `configure` in interface `ExecutionEnvironment.Settings`

### overrideCacheStrategy

    public boolean overrideCacheStrategy()

  Specified by:
    `overrideCacheStrategy` in interface `ExecutionEnvironment.Settings`

### getCacheConcurrencyStrategy

    public String getCacheConcurrencyStrategy()

  Specified by:
    `getCacheConcurrencyStrategy` in interface `ExecutionEnvironment.Settings`

### afterSessionFactoryBuilt

    public void afterSessionFactoryBuilt(SessionFactoryImplementor sfi)

  Specified by:
    `afterSessionFactoryBuilt` in interface `ExecutionEnvironment.Settings`

### afterConfigurationBuilt

    public void afterConfigurationBuilt(Mappings mappings,
                                        Dialect dialect)

  Specified by:
    `afterConfigurationBuilt` in interface `ExecutionEnvironment.Settings`

### appliesTo

    public boolean appliesTo(Dialect dialect)

  Intended to indicate that this test class as a whole is intended for a dialect or series of dialects. Skips here (appliesTo = false) therefore simply indicate that the given tests target a particular feature of the checked database and none of the tests on this class should be run for the checked dialect.

  Specified by:
    `appliesTo` in interface `ExecutionEnvironment.Settings`
  Parameters:
    `dialect` - The dialect to be checked.
  Returns:
    False if the test class as a whole is specifically targetting a dialect (or series of dialects) other than the indicated dialect and the test should therefore be skipped in its entirety; true otherwise.

### getSessions

    protected SessionFactory getSessions()

  Get the factory for this test environment.

  Returns:
    The factory.

### sfi

    protected SessionFactoryImplementor sfi()

  Get the factory for this test environment, casted to `SessionFactoryImplementor`.

  Shorthand for ( `SessionFactoryImplementor` ) `getSessions()`...

  Returns:
    The factory

### getDialect

    protected Dialect getDialect()

### getCfg

    protected Configuration getCfg()

### openSession

    public Session openSession()
                        throws HibernateException

  Throws:
    `HibernateException`

### openSession

    public Session openSession(Interceptor interceptor)
                        throws HibernateException

  Throws:
    `HibernateException`

### isSerializableIsolationEnforced

    protected boolean isSerializableIsolationEnforced()
                                               throws Exception

  Do connections enforce SERIALIZABLE isolation...

  Returns:
  Throws:
    `Exception`

### readCommittedIsolationMaintained

    protected boolean readCommittedIsolationMaintained(String scenario)

  Is connection at least read committed?

  Not, that this skip check relies on the JDBC driver reporting the true isolation level correctly. HSQLDB, for example, will report whatever you specify as the isolation (Connection.setTransationIsolation()), even though it only supports read-uncommitted.

  Parameters:
    `scenario` - text description of the scenario being tested.
  Returns:
    true if read-committed isolation is maintained.

### allowsPhysicalColumnNameInOrderby

    protected boolean allowsPhysicalColumnNameInOrderby(String testDescription)

  Does the db/dialect support using a column's physical name in the order-by clause even after it has been aliased in the select clause. This is not actually required by the SQL spec, although virtually ever DB in the world supports this (the most glaring omission here being IBM-variant DBs ala DB2 and Derby).

  Parameters:
    `testDescription` - description of the scenario being tested.
  Returns:
    true if is allowed

### allowsPhysicalColumnNameInHaving

    protected boolean allowsPhysicalColumnNameInHaving(String testDescription)

  Does the db/dialect support using a column's physical name in the having clause even after it has been aliased in the select/group-by clause. This is not actually required by the SQL spec, although virtually ever DB in the world supports this.

  Parameters:
    `testDescription` - description of the scenario being tested.
  Returns:
    true if is allowed

### dialectSupportsEmptyInList

    protected boolean dialectSupportsEmptyInList(String testDescription)

  Does the db/dialect support empty lists in the IN operator?

  For example, is "... a.b IN () ..." supported?

  Parameters:
    `testDescription` - description of the scenario being tested.
  Returns:
    true if is allowed

### dialectIsCaseSensitive

    protected boolean dialectIsCaseSensitive(String testDescription)

  Is the db/dialect sensitive in terms of string comparisons?

  Parameters:
    `testDescription` - description of the scenario being tested.
  Returns:
    true if sensitive

### supportsResultSetPositionQueryMethodsOnForwardOnlyCursor

    protected boolean supportsResultSetPositionQueryMethodsOnForwardOnlyCursor()

### supportsCircularCascadeDelete

    protected boolean supportsCircularCascadeDelete()

### supportsSubselectOnLeftSideIn

    protected boolean supportsSubselectOnLeftSideIn()

### supportsExpectedLobUsagePattern

    protected boolean supportsExpectedLobUsagePattern()

  Expected LOB usage pattern is such that I can perform an insert via prepared statement with a parameter binding for a LOB value without crazy casting to JDBC driver implementation-specific classes...

  Part of the trickiness here is the fact that this is largely driver dependent. For Oracle, which is notoriously bad with LOB support in their drivers actually does a pretty good job with LOB support as of the 10.2.x versions of their drivers...

  Returns:
    True if expected usage pattern is support; false otherwise.

### supportsLobValueChangePropogation

    protected boolean supportsLobValueChangePropogation()

  Does the current dialect support propogating changes to LOB values back to the database? Talking about mutating the underlying value as opposed to supplying a new LOB instance...

  Returns:
    True if the changes are propogated back to the database; false otherwise.

### supportsUnboundedLobLocatorMaterialization

    protected boolean supportsUnboundedLobLocatorMaterialization()

  Is it supported to materialize a LOB locator outside the transaction in which it was created?

  Again, part of the trickiness here is the fact that this is largely driver dependent.

  NOTE: all database I have tested which `supportsExpectedLobUsagePattern()` also support the ability to materialize a LOB outside the owning transaction...

  Returns:
    True if unbounded materialization is supported; false otherwise.

### supportsSubqueryOnMutatingTable

    protected boolean supportsSubqueryOnMutatingTable()

### dialectIs

    protected boolean dialectIs(Class dialectClass)

### dialectIsOneOf

    protected boolean dialectIsOneOf(Class[] dialectClasses)

### dialectIsNot

    protected boolean dialectIsNot(Class dialectClass)

### dialectIsNot

    protected boolean dialectIsNot(Class[] dialectClasses)

Overview | Package | Class | Use | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

Copyright © 2001-2010 Red Hat, Inc. All Rights Reserved.