You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@beam.apache.org by me...@apache.org on 2017/07/19 19:17:22 UTC
[beam-site] branch mergebot updated (6a6b93a -> f6175fa)
This is an automated email from the ASF dual-hosted git repository.
mergebot-role pushed a change to branch mergebot
in repository https://gitbox.apache.org/repos/asf/beam-site.git.
from 6a6b93a This closes #257
add 7ccef23 Prepare repository for deployment.
new 7d3fc98 Port of Google doc
new b6fdf18 IO Testing, unit tests: update after readthrough
new cd40290 fixup! IO Testing, unit tests: update after readthrough
new 970991b fixup! fixup! IO Testing, unit tests: update after readthrough
new f6175fa This closes #274
The 5 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
content/documentation/io/built-in/index.html | 4 ++
src/documentation/io/io-toc.md | 3 +-
src/documentation/io/testing.md | 101 ++++++++++++++++++++++++++-
3 files changed, 106 insertions(+), 2 deletions(-)
--
To stop receiving notification emails like this one, please contact
['"commits@beam.apache.org" <co...@beam.apache.org>'].
[beam-site] 02/05: IO Testing, unit tests: update after readthrough
Posted by me...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
mergebot-role pushed a commit to branch mergebot
in repository https://gitbox.apache.org/repos/asf/beam-site.git
commit b6fdf18846cb0fdb829f41b5c5d5a8338160fc47
Author: Stephen Sisk <si...@google.com>
AuthorDate: Fri Jul 14 10:22:03 2017 -0700
IO Testing, unit tests: update after readthrough
---
src/documentation/io/testing.md | 17 ++++++++---------
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/src/documentation/io/testing.md b/src/documentation/io/testing.md
index ddab572..a1c1f46 100644
--- a/src/documentation/io/testing.md
+++ b/src/documentation/io/testing.md
@@ -23,8 +23,8 @@ This document explains the set of tests that the Beam community recommends based
While it is standard to write unit tests and integration tests, there are many possible definitions. Our definitions are:
* **Unit Tests:**
- * Goal: verifying correctness of the transform itself - core behavior, corner cases, etc.
- * Data store used: an in-memory version of the data store (if available), otherwise you'll need to write a [fake](#setting-up-mocks-fakes)
+ * Goal: verifying correctness of the transform only - core behavior, corner cases, etc.
+ * Data store used: an in-memory version of the data store (if available), otherwise you'll need to write a [fake](#use-fakes)
* Data set size: tiny (10s to 100s of rows)
* **Integration Tests:**
* Goal: catch problems that occur when interacting with real versions of the runners/data store
@@ -34,16 +34,14 @@ While it is standard to write unit tests and integration tests, there are many p
## A note on performance benchmarking
-Doing performance benchmarking is definitely useful and would provide value to the beam community. However, we do not advocate writing a separate performance test specifically for this purpose. Instead, we advocate setting up integration tests so that they be used with different runners and data set sizes.
+We do not advocate writing a separate test specifically for performance benchmarking. Instead, we advocate setting up integration tests so that they can be parameterized in a way that allows for covering many different testing scenarios.
For example, if integration tests are written according to the guidelines below, the integration tests can be run on different runners (either local or in a cluster configuration) and against a data store that is a small instance with a small data set, or a large production-ready cluster with larger data set. This can provide coverage for a variety of scenarios - one of them is performance benchmarking.
-See the Integration Testing section for more information.
-
## Test Balance - Unit vs Integration {#test-balance-unit-vs-integration}
-It's easy to cover a large amount of code with an integration test, but it is then hard to find a cause for failures and the test is flakier.
+It's easy to cover a large amount of code with an integration test, but it is then hard to find a cause for test failures and the test is flakier.
However, there is a valuable set of bugs found by tests that exercise multiple workers reading/writing to data store instances that have multiple nodes (eg, read replicas, etc.). Those scenarios are hard to find with unit tests and we find they commonly cause bugs in I/O transforms.
@@ -83,12 +81,12 @@ Our test strategy is a balance of those 2 contradictory needs. We recommend doin
A general guide to writing Unit Tests for all transforms can be found in the [PTransform Style Guide](https://beam.apache.org/contribute/ptransform-style-guide/#testing ). We have expanded on a few important points below.
-If you are implementing a `Source`/`Reader` class, make sure to exhaustively unit-test your code. A minor implementation error can lead to data corruption or data loss (such as skipping or duplicating records) that can be hard for your users to detect. Also look into using SourceTestUtils - it is a key piece of test `Source` implementations.
+If you are implementing a `Source`/`Reader` class, make sure to exhaustively unit-test your code. A minor implementation error can lead to data corruption or data loss (such as skipping or duplicating records) that can be hard for your users to detect. Also look into using `SourceTestUtils` - it is a key piece of test `Source` implementations.
If you are not using the `Source` API, you can use DoFnTester to help with your testing. Datastore's I/O transforms have some good examples of how to use it in testing I/O transforms.
-### Use mocks/fakes
+### Use fakes {#use-fakes}
Instead of using mocks in your unit tests (pre-programming exact responses to each call for each test), use fakes (a lightweight implementation of the service that behaves the same way at a very small scale) or an in-memory version of the service you're testing. This has proven to be the right mix of "you can get the conditions for testing you need" and "you don't have to write a million exacting mock function calls".
@@ -104,10 +102,11 @@ The suggested design pattern is that your I/O transform throws exceptions once i
If your I/O transform allows batching of reads/writes, you must force the batching to occur in your test. Having configurable batch size options on your I/O transform allows that to happen easily (potentially marked as test-only)
-
+<!--
# Next steps
If you have a well tested I/O transform, why not contribute it to Apache Beam? Read all about it:
[Contributing I/O Transforms]({{site.baseurl }}/documentation/io/contributing/)
+-->
--
To stop receiving notification emails like this one, please contact
"commits@beam.apache.org" <co...@beam.apache.org>.
[beam-site] 03/05: fixup! IO Testing,
unit tests: update after readthrough
Posted by me...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
mergebot-role pushed a commit to branch mergebot
in repository https://gitbox.apache.org/repos/asf/beam-site.git
commit cd402901509c4a9fdb369011014eec2094c1514c
Author: Stephen Sisk <si...@google.com>
AuthorDate: Tue Jul 18 15:08:50 2017 -0700
fixup! IO Testing, unit tests: update after readthrough
---
src/documentation/io/io-toc.md | 1 -
src/documentation/io/testing.md | 48 +++++++++++++++++++++++------------------
2 files changed, 27 insertions(+), 22 deletions(-)
diff --git a/src/documentation/io/io-toc.md b/src/documentation/io/io-toc.md
index 170321e..49c1d12 100644
--- a/src/documentation/io/io-toc.md
+++ b/src/documentation/io/io-toc.md
@@ -16,7 +16,6 @@ permalink: /documentation/io/io-toc/
> Note: This guide is still in progress. There is an open issue to finish the guide: [BEAM-1025](https://issues.apache.org/jira/browse/BEAM-1025).
* [Authoring I/O Transforms - Overview]({{site.baseurl }}/documentation/io/authoring-overview/)
-
* [Testing I/O Transforms]({{site.baseurl }}/documentation/io/testing/)
<!-- TODO: commented out until this content is ready.
diff --git a/src/documentation/io/testing.md b/src/documentation/io/testing.md
index a1c1f46..924bbe0 100644
--- a/src/documentation/io/testing.md
+++ b/src/documentation/io/testing.md
@@ -6,15 +6,20 @@ permalink: /documentation/io/testing/
[Pipeline I/O Table of Contents]({{site.baseurl}}/documentation/io/io-toc/)
-# Testing I/O Transforms
-> Note: This guide is still in progress. There is an open issue to finish the guide: [BEAM-1025](https://issues.apache.org/jira/browse/BEAM-1025).
-
-
-## Testing IO Transforms in Apache Beam
+## Testing I/O Transforms in Apache Beam
*Examples and design patterns for testing Apache Beam I/O transforms*
+<nav class="language-switcher">
+ <strong>Adapt for:</strong>
+ <ul>
+ <li data-type="language-java" class="active">Java SDK</li>
+ <li data-type="language-py">Python SDK</li>
+ </ul>
+</nav>
+
+> Note: This guide is still in progress. There is an open issue to finish the guide: [BEAM-1025](https://issues.apache.org/jira/browse/BEAM-1025).
## Introduction {#introduction}
@@ -34,7 +39,7 @@ While it is standard to write unit tests and integration tests, there are many p
## A note on performance benchmarking
-We do not advocate writing a separate test specifically for performance benchmarking. Instead, we advocate setting up integration tests so that they can be parameterized in a way that allows for covering many different testing scenarios.
+We do not advocate writing a separate test specifically for performance benchmarking. Instead, we recommend setting up integration tests that can accept the necessary parameters to cover many different testing scenarios.
For example, if integration tests are written according to the guidelines below, the integration tests can be run on different runners (either local or in a cluster configuration) and against a data store that is a small instance with a small data set, or a large production-ready cluster with larger data set. This can provide coverage for a variety of scenarios - one of them is performance benchmarking.
@@ -50,11 +55,14 @@ Our test strategy is a balance of those 2 contradictory needs. We recommend doin
## Examples {#examples}
+Java:
+* [BigtableIO](https://github.com/apache/beam/blob/master/sdks/java/io/google-cloud-platform/src/test/java/org/apache/beam/sdk/io/gcp/bigtable/BigtableIOTest.java)'s testing implementation is considered the best example of current best practices for unit testing `Source`s
+* [JdbcIO](https://github.com/apache/beam/blob/master/sdks/java/io/jdbc) has the current best practice examples for writing integration tests.
+* [ElasticsearchIO](https://github.com/apache/beam/blob/master/sdks/java/io/elasticsearch) demonstrates testing for bounded read/write
+* [MqttIO](https://github.com/apache/beam/tree/master/sdks/java/io/mqtt) and [AmpqpIO](https://github.com/apache/beam/tree/master/sdks/java/io/amqp) demonstrate unbounded read/write
-
-* `BigtableIO`'s testing implementation is considered the best example of current best practices for unit testing `Source`s.
-* `DatastoreIO` best demonstrates usage of the Service interface design pattern.
-* `JdbcIO` has the current best practice examples for writing integration tests.
+Python:
+* [avroio_test](https://github.com/apache/beam/blob/master/sdks/python/apache_beam/io/avroio_test.py) for examples of testing liquid sharding, `source_test_utils`, `assert_that` and `equal_to`
## Unit Tests {#unit-tests}
@@ -62,18 +70,14 @@ Our test strategy is a balance of those 2 contradictory needs. We recommend doin
### Goals {#goals}
-
-
* Validate the correctness of the code in your I/O transform.
* Validate that the I/O transform works correctly when used in concert with reference implementations of the data store it connects with (where "reference implementation" means a fake or in-memory version).
-* Be able to run quickly (< 1 sec) and need only one machine, with a reasonably small memory/disk footprint and no non-local network access (preferably none at all).
+* Be able to run quickly and need only one machine, with a reasonably small memory/disk footprint and no non-local network access (preferably none at all). Aim for tests than run within several seconds - anything above 20 seconds should be discussed with the beam dev mailing list.
* Validate that the I/O transform can handle network failures.
### Non-goals
-
-
* Test problems in the external data store - this can lead to extremely complicated tests.
@@ -81,26 +85,28 @@ Our test strategy is a balance of those 2 contradictory needs. We recommend doin
A general guide to writing Unit Tests for all transforms can be found in the [PTransform Style Guide](https://beam.apache.org/contribute/ptransform-style-guide/#testing ). We have expanded on a few important points below.
-If you are implementing a `Source`/`Reader` class, make sure to exhaustively unit-test your code. A minor implementation error can lead to data corruption or data loss (such as skipping or duplicating records) that can be hard for your users to detect. Also look into using `SourceTestUtils` - it is a key piece of test `Source` implementations.
+If you are using the `Source` API, make sure to exhaustively unit-test your code. A minor implementation error can lead to data corruption or data loss (such as skipping or duplicating records) that can be hard for your users to detect. Also look into using <span class="language-java">`SourceTestUtils`</span><span class="language-py">`source_test_utils`</span> - it is a key piece of testing `Source` implementations.
+
+If you are not using the `Source` API, you can use `TestPipeline` with <span class="language-java">`PAssert`</span><span class="language-py">`assert_that`</span> to help with your testing.
-If you are not using the `Source` API, you can use DoFnTester to help with your testing. Datastore's I/O transforms have some good examples of how to use it in testing I/O transforms.
+If you are implementing write, you can use `TestPipeline` to write test data and then read and verify it using a non-Beam client.
### Use fakes {#use-fakes}
-Instead of using mocks in your unit tests (pre-programming exact responses to each call for each test), use fakes (a lightweight implementation of the service that behaves the same way at a very small scale) or an in-memory version of the service you're testing. This has proven to be the right mix of "you can get the conditions for testing you need" and "you don't have to write a million exacting mock function calls".
+Instead of using mocks in your unit tests (pre-programming exact responses to each call for each test), use fakes. The preferred way to use fakes for I/O transform testing is to use a pre-existing in-memory/embeddable version of the service you're testing, but if one does not exist consider implementing your own. Fakes have proven to be the right mix of "you can get the conditions for testing you need" and "you don't have to write a million exacting mock function calls".
### Network failure
-To help with testing and separation of concerns, **code that interacts across a network should be handled in a separate class from your I/O transform**, and thus should be unit tested separately from the I/O transform itself. In many cases, necessary network retries should be encapsulated within a fake implementation.
+To help with testing and separation of concerns, **code that interacts across a network should be handled in a separate class from your I/O transform**. The suggested design pattern is that your I/O transform throws exceptions once it determines that a read is no longer possible.
-The suggested design pattern is that your I/O transform throws exceptions once it determines that a read is no longer possible. This allows the I/O transform's unit tests to act as if they have a perfect network connection, and they do not need to retry/otherwise handle network connection problems.
+This allows the I/O transform's unit tests to act as if they have a perfect network connection, and they do not need to retry/otherwise handle network connection problems.
## Batching
-If your I/O transform allows batching of reads/writes, you must force the batching to occur in your test. Having configurable batch size options on your I/O transform allows that to happen easily (potentially marked as test-only)
+If your I/O transform allows batching of reads/writes, you must force the batching to occur in your test. Having configurable batch size options on your I/O transform allows that to happen easily. These must be marked as test only.
<!--
# Next steps
--
To stop receiving notification emails like this one, please contact
"commits@beam.apache.org" <co...@beam.apache.org>.
[beam-site] 01/05: Port of Google doc
Posted by me...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
mergebot-role pushed a commit to branch mergebot
in repository https://gitbox.apache.org/repos/asf/beam-site.git
commit 7d3fc98a1371baa38fddcf7a821766efa4b6ad00
Author: Stephen Sisk <si...@google.com>
AuthorDate: Fri Jul 14 09:59:59 2017 -0700
Port of Google doc
---
src/documentation/io/io-toc.md | 4 +-
src/documentation/io/testing.md | 94 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 97 insertions(+), 1 deletion(-)
diff --git a/src/documentation/io/io-toc.md b/src/documentation/io/io-toc.md
index 811f70a..170321e 100644
--- a/src/documentation/io/io-toc.md
+++ b/src/documentation/io/io-toc.md
@@ -17,9 +17,11 @@ permalink: /documentation/io/io-toc/
* [Authoring I/O Transforms - Overview]({{site.baseurl }}/documentation/io/authoring-overview/)
+* [Testing I/O Transforms]({{site.baseurl }}/documentation/io/testing/)
+
<!-- TODO: commented out until this content is ready.
* [Authoring I/O Transforms - Python]({{site.baseurl }}/documentation/io/authoring-python/)
* [Authoring I/O Transforms - Java]({{site.baseurl }}/documentation/io/authoring-java/)
-* [Testing I/O Transforms]({{site.baseurl }}/documentation/io/testing/)
+
* [Contributing I/O Transforms]({{site.baseurl }}/documentation/io/contributing/)
-->
diff --git a/src/documentation/io/testing.md b/src/documentation/io/testing.md
index e43c628..ddab572 100644
--- a/src/documentation/io/testing.md
+++ b/src/documentation/io/testing.md
@@ -11,6 +11,100 @@ permalink: /documentation/io/testing/
> Note: This guide is still in progress. There is an open issue to finish the guide: [BEAM-1025](https://issues.apache.org/jira/browse/BEAM-1025).
+## Testing IO Transforms in Apache Beam
+
+*Examples and design patterns for testing Apache Beam I/O transforms*
+
+
+## Introduction {#introduction}
+
+This document explains the set of tests that the Beam community recommends based on our past experience writing I/O transforms. If you wish to contribute your I/O transform to the Beam community, we'll ask you to implement these tests.
+
+While it is standard to write unit tests and integration tests, there are many possible definitions. Our definitions are:
+
+* **Unit Tests:**
+ * Goal: verifying correctness of the transform itself - core behavior, corner cases, etc.
+ * Data store used: an in-memory version of the data store (if available), otherwise you'll need to write a [fake](#setting-up-mocks-fakes)
+ * Data set size: tiny (10s to 100s of rows)
+* **Integration Tests:**
+ * Goal: catch problems that occur when interacting with real versions of the runners/data store
+ * Data store used: an actual instance, pre-configured before the test
+ * Data set size: small to medium (1000 rows to 10s of GBs)
+
+
+## A note on performance benchmarking
+
+Doing performance benchmarking is definitely useful and would provide value to the beam community. However, we do not advocate writing a separate performance test specifically for this purpose. Instead, we advocate setting up integration tests so that they be used with different runners and data set sizes.
+
+For example, if integration tests are written according to the guidelines below, the integration tests can be run on different runners (either local or in a cluster configuration) and against a data store that is a small instance with a small data set, or a large production-ready cluster with larger data set. This can provide coverage for a variety of scenarios - one of them is performance benchmarking.
+
+See the Integration Testing section for more information.
+
+
+## Test Balance - Unit vs Integration {#test-balance-unit-vs-integration}
+
+It's easy to cover a large amount of code with an integration test, but it is then hard to find a cause for failures and the test is flakier.
+
+However, there is a valuable set of bugs found by tests that exercise multiple workers reading/writing to data store instances that have multiple nodes (eg, read replicas, etc.). Those scenarios are hard to find with unit tests and we find they commonly cause bugs in I/O transforms.
+
+Our test strategy is a balance of those 2 contradictory needs. We recommend doing as much testing as possible in unit tests, and writing a single, small integration test that can be run in various configurations.
+
+
+## Examples {#examples}
+
+
+
+* `BigtableIO`'s testing implementation is considered the best example of current best practices for unit testing `Source`s.
+* `DatastoreIO` best demonstrates usage of the Service interface design pattern.
+* `JdbcIO` has the current best practice examples for writing integration tests.
+
+
+## Unit Tests {#unit-tests}
+
+
+### Goals {#goals}
+
+
+
+* Validate the correctness of the code in your I/O transform.
+* Validate that the I/O transform works correctly when used in concert with reference implementations of the data store it connects with (where "reference implementation" means a fake or in-memory version).
+* Be able to run quickly (< 1 sec) and need only one machine, with a reasonably small memory/disk footprint and no non-local network access (preferably none at all).
+* Validate that the I/O transform can handle network failures.
+
+
+### Non-goals
+
+
+
+* Test problems in the external data store - this can lead to extremely complicated tests.
+
+
+### Implementing unit tests {#implementing-unit-tests}
+
+A general guide to writing Unit Tests for all transforms can be found in the [PTransform Style Guide](https://beam.apache.org/contribute/ptransform-style-guide/#testing ). We have expanded on a few important points below.
+
+If you are implementing a `Source`/`Reader` class, make sure to exhaustively unit-test your code. A minor implementation error can lead to data corruption or data loss (such as skipping or duplicating records) that can be hard for your users to detect. Also look into using SourceTestUtils - it is a key piece of test `Source` implementations.
+
+If you are not using the `Source` API, you can use DoFnTester to help with your testing. Datastore's I/O transforms have some good examples of how to use it in testing I/O transforms.
+
+
+### Use mocks/fakes
+
+Instead of using mocks in your unit tests (pre-programming exact responses to each call for each test), use fakes (a lightweight implementation of the service that behaves the same way at a very small scale) or an in-memory version of the service you're testing. This has proven to be the right mix of "you can get the conditions for testing you need" and "you don't have to write a million exacting mock function calls".
+
+
+### Network failure
+
+To help with testing and separation of concerns, **code that interacts across a network should be handled in a separate class from your I/O transform**, and thus should be unit tested separately from the I/O transform itself. In many cases, necessary network retries should be encapsulated within a fake implementation.
+
+The suggested design pattern is that your I/O transform throws exceptions once it determines that a read is no longer possible. This allows the I/O transform's unit tests to act as if they have a perfect network connection, and they do not need to retry/otherwise handle network connection problems.
+
+
+## Batching
+
+If your I/O transform allows batching of reads/writes, you must force the batching to occur in your test. Having configurable batch size options on your I/O transform allows that to happen easily (potentially marked as test-only)
+
+
# Next steps
If you have a well tested I/O transform, why not contribute it to Apache Beam? Read all about it:
--
To stop receiving notification emails like this one, please contact
"commits@beam.apache.org" <co...@beam.apache.org>.
[beam-site] 05/05: This closes #274
Posted by me...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
mergebot-role pushed a commit to branch mergebot
in repository https://gitbox.apache.org/repos/asf/beam-site.git
commit f6175fa4591a9e0d564da3943509f60fcd8d59e9
Merge: 7ccef23 970991b
Author: Mergebot <me...@apache.org>
AuthorDate: Wed Jul 19 19:17:10 2017 +0000
This closes #274
src/documentation/io/io-toc.md | 3 +-
src/documentation/io/testing.md | 101 +++++++++++++++++++++++++++++++++++++++-
2 files changed, 102 insertions(+), 2 deletions(-)
--
To stop receiving notification emails like this one, please contact
"commits@beam.apache.org" <co...@beam.apache.org>.
[beam-site] 04/05: fixup! fixup! IO Testing,
unit tests: update after readthrough
Posted by me...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
mergebot-role pushed a commit to branch mergebot
in repository https://gitbox.apache.org/repos/asf/beam-site.git
commit 970991b7d0052244a15a07d409771f3721ca233e
Author: Stephen Sisk <si...@google.com>
AuthorDate: Wed Jul 19 10:20:59 2017 -0700
fixup! fixup! IO Testing, unit tests: update after readthrough
---
src/documentation/io/testing.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/documentation/io/testing.md b/src/documentation/io/testing.md
index 924bbe0..adfde04 100644
--- a/src/documentation/io/testing.md
+++ b/src/documentation/io/testing.md
@@ -99,7 +99,7 @@ Instead of using mocks in your unit tests (pre-programming exact responses to ea
### Network failure
-To help with testing and separation of concerns, **code that interacts across a network should be handled in a separate class from your I/O transform**. The suggested design pattern is that your I/O transform throws exceptions once it determines that a read is no longer possible.
+To help with testing and separation of concerns, **code that interacts across a network should be handled in a separate class from your I/O transform**. The suggested design pattern is that your I/O transform throws exceptions once it determines that a read or write is no longer possible.
This allows the I/O transform's unit tests to act as if they have a perfect network connection, and they do not need to retry/otherwise handle network connection problems.
--
To stop receiving notification emails like this one, please contact
"commits@beam.apache.org" <co...@beam.apache.org>.