[#5452] Add a big disclaimer to the Mock API not to mock an entire database

This commit is contained in:
lukaseder 2016-07-25 10:40:56 +02:00
parent 3450682eb8
commit 7528b7645f
10 changed files with 87 additions and 42 deletions

View File

@ -9893,9 +9893,13 @@ create.selectFrom(AUTHOR)
<section id="jdbc-mocking">
<title>JDBC mocking for unit testing</title>
<content><html>
<p>
When writing unit tests for your data access layer, you have probably used some generic mocking tool offered by popular providers like <a href="http://code.google.com/p/mockito/">Mockito</a>, <a href="http://jmock.org/">jmock</a>, <a href="http://mockrunner.sourceforge.net/">mockrunner</a>, or even <a href="http://www.dbunit.org/">DBUnit</a>. With jOOQ, you can take advantage of the built-in JDBC mock API that allows you to emulate a database on the JDBC level for precisely those SQL/JDBC use cases supported by jOOQ.
</p>
<p>
When writing unit tests for your data access layer, you have probably used some generic mocking tool offered by popular providers like <a href="http://code.google.com/p/mockito/">Mockito</a>, <a href="http://jmock.org/">jmock</a>, <a href="http://mockrunner.sourceforge.net/">mockrunner</a>, or even <a href="http://www.dbunit.org/">DBUnit</a>. With jOOQ, you can take advantage of the built-in JDBC mock API that allows you to emulate a simple database on the JDBC level for precisely those SQL/JDBC use cases supported by jOOQ.
</p>
<p>
<strong>Disclaimer: </strong> The general idea of mocking a JDBC connection with this jOOQ API is to provide quick workarounds, injection points, etc. using a very simple JDBC abstraction. It is <em>NOT RECOMMENDED</em> to emulate an entire database (including complex state transitions, transactions, locking, etc.) using this mock API. Once you have this requirement, please consider using an actual database instead for integration testing, rather than implementing your test database inside of a <code>MockDataProvider</code>.
</p>
<h3>Mocking the JDBC API</h3>
<p>

View File

@ -10398,9 +10398,13 @@ create.selectFrom(AUTHOR)
<section id="jdbc-mocking">
<title>JDBC mocking for unit testing</title>
<content><html>
<p>
When writing unit tests for your data access layer, you have probably used some generic mocking tool offered by popular providers like <a href="http://code.google.com/p/mockito/">Mockito</a>, <a href="http://jmock.org/">jmock</a>, <a href="http://mockrunner.sourceforge.net/">mockrunner</a>, or even <a href="http://www.dbunit.org/">DBUnit</a>. With jOOQ, you can take advantage of the built-in JDBC mock API that allows you to emulate a database on the JDBC level for precisely those SQL/JDBC use cases supported by jOOQ.
</p>
<p>
When writing unit tests for your data access layer, you have probably used some generic mocking tool offered by popular providers like <a href="http://code.google.com/p/mockito/">Mockito</a>, <a href="http://jmock.org/">jmock</a>, <a href="http://mockrunner.sourceforge.net/">mockrunner</a>, or even <a href="http://www.dbunit.org/">DBUnit</a>. With jOOQ, you can take advantage of the built-in JDBC mock API that allows you to emulate a simple database on the JDBC level for precisely those SQL/JDBC use cases supported by jOOQ.
</p>
<p>
<strong>Disclaimer: </strong> The general idea of mocking a JDBC connection with this jOOQ API is to provide quick workarounds, injection points, etc. using a very simple JDBC abstraction. It is <em>NOT RECOMMENDED</em> to emulate an entire database (including complex state transitions, transactions, locking, etc.) using this mock API. Once you have this requirement, please consider using an actual database instead for integration testing, rather than implementing your test database inside of a <code>MockDataProvider</code>.
</p>
<h3>Mocking the JDBC API</h3>
<p>

View File

@ -11119,9 +11119,13 @@ create.selectFrom(AUTHOR)
<section id="jdbc-mocking">
<title>JDBC mocking for unit testing</title>
<content><html>
<p>
When writing unit tests for your data access layer, you have probably used some generic mocking tool offered by popular providers like <a href="http://code.google.com/p/mockito/">Mockito</a>, <a href="http://jmock.org/">jmock</a>, <a href="http://mockrunner.sourceforge.net/">mockrunner</a>, or even <a href="http://www.dbunit.org/">DBUnit</a>. With jOOQ, you can take advantage of the built-in JDBC mock API that allows you to emulate a database on the JDBC level for precisely those SQL/JDBC use cases supported by jOOQ.
</p>
<p>
When writing unit tests for your data access layer, you have probably used some generic mocking tool offered by popular providers like <a href="http://code.google.com/p/mockito/">Mockito</a>, <a href="http://jmock.org/">jmock</a>, <a href="http://mockrunner.sourceforge.net/">mockrunner</a>, or even <a href="http://www.dbunit.org/">DBUnit</a>. With jOOQ, you can take advantage of the built-in JDBC mock API that allows you to emulate a simple database on the JDBC level for precisely those SQL/JDBC use cases supported by jOOQ.
</p>
<p>
<strong>Disclaimer: </strong> The general idea of mocking a JDBC connection with this jOOQ API is to provide quick workarounds, injection points, etc. using a very simple JDBC abstraction. It is <em>NOT RECOMMENDED</em> to emulate an entire database (including complex state transitions, transactions, locking, etc.) using this mock API. Once you have this requirement, please consider using an actual database instead for integration testing, rather than implementing your test database inside of a <code>MockDataProvider</code>.
</p>
<h3>Mocking the JDBC API</h3>
<p>

View File

@ -12016,9 +12016,13 @@ create.selectFrom(AUTHOR)
<section id="jdbc-mocking">
<title>JDBC mocking for unit testing</title>
<content><html>
<p>
When writing unit tests for your data access layer, you have probably used some generic mocking tool offered by popular providers like <a href="http://code.google.com/p/mockito/">Mockito</a>, <a href="http://jmock.org/">jmock</a>, <a href="http://mockrunner.sourceforge.net/">mockrunner</a>, or even <a href="http://www.dbunit.org/">DBUnit</a>. With jOOQ, you can take advantage of the built-in JDBC mock API that allows you to emulate a database on the JDBC level for precisely those SQL/JDBC use cases supported by jOOQ.
</p>
<p>
When writing unit tests for your data access layer, you have probably used some generic mocking tool offered by popular providers like <a href="http://code.google.com/p/mockito/">Mockito</a>, <a href="http://jmock.org/">jmock</a>, <a href="http://mockrunner.sourceforge.net/">mockrunner</a>, or even <a href="http://www.dbunit.org/">DBUnit</a>. With jOOQ, you can take advantage of the built-in JDBC mock API that allows you to emulate a simple database on the JDBC level for precisely those SQL/JDBC use cases supported by jOOQ.
</p>
<p>
<strong>Disclaimer: </strong> The general idea of mocking a JDBC connection with this jOOQ API is to provide quick workarounds, injection points, etc. using a very simple JDBC abstraction. It is <em>NOT RECOMMENDED</em> to emulate an entire database (including complex state transitions, transactions, locking, etc.) using this mock API. Once you have this requirement, please consider using an actual database instead for integration testing, rather than implementing your test database inside of a <code>MockDataProvider</code>.
</p>
<h3>Mocking the JDBC API</h3>
<p>

View File

@ -13177,9 +13177,13 @@ create.selectFrom(AUTHOR)
<section id="jdbc-mocking">
<title>JDBC mocking for unit testing</title>
<content><html>
<p>
When writing unit tests for your data access layer, you have probably used some generic mocking tool offered by popular providers like <a href="http://code.google.com/p/mockito/">Mockito</a>, <a href="http://jmock.org/">jmock</a>, <a href="http://mockrunner.sourceforge.net/">mockrunner</a>, or even <a href="http://www.dbunit.org/">DBUnit</a>. With jOOQ, you can take advantage of the built-in JDBC mock API that allows you to emulate a database on the JDBC level for precisely those SQL/JDBC use cases supported by jOOQ.
</p>
<p>
When writing unit tests for your data access layer, you have probably used some generic mocking tool offered by popular providers like <a href="http://code.google.com/p/mockito/">Mockito</a>, <a href="http://jmock.org/">jmock</a>, <a href="http://mockrunner.sourceforge.net/">mockrunner</a>, or even <a href="http://www.dbunit.org/">DBUnit</a>. With jOOQ, you can take advantage of the built-in JDBC mock API that allows you to emulate a simple database on the JDBC level for precisely those SQL/JDBC use cases supported by jOOQ.
</p>
<p>
<strong>Disclaimer: </strong> The general idea of mocking a JDBC connection with this jOOQ API is to provide quick workarounds, injection points, etc. using a very simple JDBC abstraction. It is <em>NOT RECOMMENDED</em> to emulate an entire database (including complex state transitions, transactions, locking, etc.) using this mock API. Once you have this requirement, please consider using an actual database instead for integration testing, rather than implementing your test database inside of a <code>MockDataProvider</code>.
</p>
<h3>Mocking the JDBC API</h3>
<p>

View File

@ -13881,9 +13881,13 @@ public class PostgresJSONGsonBinding implements Binding<Object, JsonElement> {
<section id="jdbc-mocking">
<title>JDBC mocking for unit testing</title>
<content><html>
<p>
When writing unit tests for your data access layer, you have probably used some generic mocking tool offered by popular providers like <a href="http://code.google.com/p/mockito/">Mockito</a>, <a href="http://jmock.org/">jmock</a>, <a href="http://mockrunner.sourceforge.net/">mockrunner</a>, or even <a href="http://www.dbunit.org/">DBUnit</a>. With jOOQ, you can take advantage of the built-in JDBC mock API that allows you to emulate a database on the JDBC level for precisely those SQL/JDBC use cases supported by jOOQ.
</p>
<p>
When writing unit tests for your data access layer, you have probably used some generic mocking tool offered by popular providers like <a href="http://code.google.com/p/mockito/">Mockito</a>, <a href="http://jmock.org/">jmock</a>, <a href="http://mockrunner.sourceforge.net/">mockrunner</a>, or even <a href="http://www.dbunit.org/">DBUnit</a>. With jOOQ, you can take advantage of the built-in JDBC mock API that allows you to emulate a simple database on the JDBC level for precisely those SQL/JDBC use cases supported by jOOQ.
</p>
<p>
<strong>Disclaimer: </strong> The general idea of mocking a JDBC connection with this jOOQ API is to provide quick workarounds, injection points, etc. using a very simple JDBC abstraction. It is <em>NOT RECOMMENDED</em> to emulate an entire database (including complex state transitions, transactions, locking, etc.) using this mock API. Once you have this requirement, please consider using an actual database instead for integration testing, rather than implementing your test database inside of a <code>MockDataProvider</code>.
</p>
<h3>Mocking the JDBC API</h3>
<p>

View File

@ -14767,9 +14767,13 @@ public class Book {
<section id="jdbc-mocking">
<title>JDBC mocking for unit testing</title>
<content><html>
<p>
When writing unit tests for your data access layer, you have probably used some generic mocking tool offered by popular providers like <a href="http://code.google.com/p/mockito/">Mockito</a>, <a href="http://jmock.org/">jmock</a>, <a href="http://mockrunner.sourceforge.net/">mockrunner</a>, or even <a href="http://www.dbunit.org/">DBUnit</a>. With jOOQ, you can take advantage of the built-in JDBC mock API that allows you to emulate a database on the JDBC level for precisely those SQL/JDBC use cases supported by jOOQ.
</p>
<p>
When writing unit tests for your data access layer, you have probably used some generic mocking tool offered by popular providers like <a href="http://code.google.com/p/mockito/">Mockito</a>, <a href="http://jmock.org/">jmock</a>, <a href="http://mockrunner.sourceforge.net/">mockrunner</a>, or even <a href="http://www.dbunit.org/">DBUnit</a>. With jOOQ, you can take advantage of the built-in JDBC mock API that allows you to emulate a simple database on the JDBC level for precisely those SQL/JDBC use cases supported by jOOQ.
</p>
<p>
<strong>Disclaimer: </strong> The general idea of mocking a JDBC connection with this jOOQ API is to provide quick workarounds, injection points, etc. using a very simple JDBC abstraction. It is <em>NOT RECOMMENDED</em> to emulate an entire database (including complex state transitions, transactions, locking, etc.) using this mock API. Once you have this requirement, please consider using an actual database instead for integration testing, rather than implementing your test database inside of a <code>MockDataProvider</code>.
</p>
<h3>Mocking the JDBC API</h3>
<p>

View File

@ -15147,9 +15147,13 @@ public class Book {
<section id="jdbc-mocking">
<title>JDBC mocking for unit testing</title>
<content><html>
<p>
When writing unit tests for your data access layer, you have probably used some generic mocking tool offered by popular providers like <a href="http://code.google.com/p/mockito/">Mockito</a>, <a href="http://jmock.org/">jmock</a>, <a href="http://mockrunner.sourceforge.net/">mockrunner</a>, or even <a href="http://www.dbunit.org/">DBUnit</a>. With jOOQ, you can take advantage of the built-in JDBC mock API that allows you to emulate a database on the JDBC level for precisely those SQL/JDBC use cases supported by jOOQ.
</p>
<p>
When writing unit tests for your data access layer, you have probably used some generic mocking tool offered by popular providers like <a href="http://code.google.com/p/mockito/">Mockito</a>, <a href="http://jmock.org/">jmock</a>, <a href="http://mockrunner.sourceforge.net/">mockrunner</a>, or even <a href="http://www.dbunit.org/">DBUnit</a>. With jOOQ, you can take advantage of the built-in JDBC mock API that allows you to emulate a simple database on the JDBC level for precisely those SQL/JDBC use cases supported by jOOQ.
</p>
<p>
<strong>Disclaimer: </strong> The general idea of mocking a JDBC connection with this jOOQ API is to provide quick workarounds, injection points, etc. using a very simple JDBC abstraction. It is <em>NOT RECOMMENDED</em> to emulate an entire database (including complex state transitions, transactions, locking, etc.) using this mock API. Once you have this requirement, please consider using an actual database instead for integration testing, rather than implementing your test database inside of a <code>MockDataProvider</code>.
</p>
<h3>Mocking the JDBC API</h3>
<p>

View File

@ -15295,9 +15295,13 @@ public class Book {
<title>JDBC mocking for unit testing</title>
<content><html>
<p>
When writing unit tests for your data access layer, you have probably used some generic mocking tool offered by popular providers like <a href="http://code.google.com/p/mockito/">Mockito</a>, <a href="http://jmock.org/">jmock</a>, <a href="http://mockrunner.sourceforge.net/">mockrunner</a>, or even <a href="http://www.dbunit.org/">DBUnit</a>. With jOOQ, you can take advantage of the built-in JDBC mock API that allows you to emulate a database on the JDBC level for precisely those SQL/JDBC use cases supported by jOOQ.
When writing unit tests for your data access layer, you have probably used some generic mocking tool offered by popular providers like <a href="http://code.google.com/p/mockito/">Mockito</a>, <a href="http://jmock.org/">jmock</a>, <a href="http://mockrunner.sourceforge.net/">mockrunner</a>, or even <a href="http://www.dbunit.org/">DBUnit</a>. With jOOQ, you can take advantage of the built-in JDBC mock API that allows you to emulate a simple database on the JDBC level for precisely those SQL/JDBC use cases supported by jOOQ.
</p>
<p>
<strong>Disclaimer: </strong> The general idea of mocking a JDBC connection with this jOOQ API is to provide quick workarounds, injection points, etc. using a very simple JDBC abstraction. It is <em>NOT RECOMMENDED</em> to emulate an entire database (including complex state transitions, transactions, locking, etc.) using this mock API. Once you have this requirement, please consider using an actual database instead for integration testing, rather than implementing your test database inside of a <code>MockDataProvider</code>.
</p>
<h3>Mocking the JDBC API</h3>
<p>
JDBC is a very complex API. It takes a lot of time to write a useful and correct mock implementation, implementing at least these interfaces:

View File

@ -55,7 +55,16 @@ import org.jooq.ResultQuery;
* Supply this data provider to your {@link MockConnection} in order to globally
* provide data for SQL statements.
* <p>
* See {@link #execute(MockExecuteContext)} for details.
* The general idea of mocking a JDBC connection with this jOOQ API is to
* provide quick workarounds, injection points, etc. using a <em>very
* simple</em> JDBC abstraction (see the {@link #execute(MockExecuteContext)}
* method). It is <em>NOT RECOMMENDED</em> to emulate an entire database
* (including complex state transitions, transactions, locking, etc.) using this
* mock API. Once you have this requirement, please consider using an actual
* database instead for integration testing, rather than implementing your test
* database inside of a {@link MockDataProvider}.
* <p>
* See {@link #execute(MockExecuteContext)} for more details.
*
* @author Lukas Eder
* @see MockConnection
@ -72,19 +81,19 @@ public interface MockDataProvider {
* statement execution methods. These include:
* <p>
* <ul>
* <li> {@link Statement#execute(String)}</li>
* <li> {@link Statement#execute(String, int)}</li>
* <li> {@link Statement#execute(String, int[])}</li>
* <li> {@link Statement#execute(String, String[])}</li>
* <li> {@link Statement#executeBatch()}</li>
* <li> {@link Statement#executeQuery(String)}</li>
* <li> {@link Statement#executeUpdate(String)}</li>
* <li> {@link Statement#executeUpdate(String, int)}</li>
* <li> {@link Statement#executeUpdate(String, int[])}</li>
* <li> {@link Statement#executeUpdate(String, String[])}</li>
* <li> {@link PreparedStatement#execute()}</li>
* <li> {@link PreparedStatement#executeQuery()}</li>
* <li> {@link PreparedStatement#executeUpdate()}</li>
* <li>{@link Statement#execute(String)}</li>
* <li>{@link Statement#execute(String, int)}</li>
* <li>{@link Statement#execute(String, int[])}</li>
* <li>{@link Statement#execute(String, String[])}</li>
* <li>{@link Statement#executeBatch()}</li>
* <li>{@link Statement#executeQuery(String)}</li>
* <li>{@link Statement#executeUpdate(String)}</li>
* <li>{@link Statement#executeUpdate(String, int)}</li>
* <li>{@link Statement#executeUpdate(String, int[])}</li>
* <li>{@link Statement#executeUpdate(String, String[])}</li>
* <li>{@link PreparedStatement#execute()}</li>
* <li>{@link PreparedStatement#executeQuery()}</li>
* <li>{@link PreparedStatement#executeUpdate()}</li>
* </ul>
* <p>
* The various execution modes are unified into this simple method.
@ -132,9 +141,9 @@ public interface MockDataProvider {
* relevant flag is passed from <code>MockStatement</code> to any of these
* properties:
* <ul>
* <li> {@link MockExecuteContext#autoGeneratedKeys()}</li>
* <li> {@link MockExecuteContext#columnIndexes()}</li>
* <li> {@link MockExecuteContext#columnNames()}</li>
* <li>{@link MockExecuteContext#autoGeneratedKeys()}</li>
* <li>{@link MockExecuteContext#columnIndexes()}</li>
* <li>{@link MockExecuteContext#columnNames()}</li>
* </ul>
* </li>
* <li>OUT parameters from stored procedures are generated from the first