I spent the day with them we discussed a lot of things I had to Google:
Approval Testing
Approval tests take a snapshot of the results, and confirm that they have not changed.
http://approvaltests.sourceforge.net/
http://www.slideshare.net/lynnlangit/approval-tests-an-open-source-unit-testing-library-for-net-java-ruby-or-php-12532737
Golden Master Pattern
Find a way to capture the output of the system without changing the production code
Think if that output can be “stolen” without changing the production code. For example you could “steal” the console output by redirecting the stream of the console to an in-memory stream. Another example would be injecting an implementation of a data layer interface that would write to another data source than the production code would.
Find a pattern of the outputs
The output of the system could be text or a data structures tree or another type of stream. Starting from this output type you can decide if you could go on to the next step.
Generate enough random inputs and persist the tuple input/output
In the case you can persist the outputs to a simple data repository, you can think about what are the inputs for the corresponding outputs. Here the magic consists in finding a good balance of random or pseudo-random inputs. We need inputs that would cover most of the system with tests, but in the same time the test would run in seconds. For example in the case of a text generating algorithm we need to decide if we want to feed the system with 1000 or one million entry data. Maybe 10 000 input data are enough. We will anyway check the tests coverage during the last stage.
We need to persist the pair input-output. The output would be the Golden Master, the reference data we will always check our SUT against.
Write a system test to check the SUT against the previously persisted data
Now that we have a way to “steal” the outputs and we have a guess about how to generate enough input-output pairs, but not to many, we can call the system and check it against the outputs for a given input. We need to check if the test touches the SUT and if it passes. We also need to check that the test runs fast enough, in seconds.
Commit the test
Always when a green test passes we need to commit the code to a local source control system. Why? So that we can easily revert to a stable testable system.
Important: Do not forget to commit also the golden masters (files, database, etc)!
Check test behaviour and coverage
Hexagonal Architecture (http://alistair.cockburn.us/Hexagonal+architecture)
Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases.
As events arrive from the outside world at a port, a technology-specific adapter converts it into a usable procedure call or message and passes it to the application. The application is blissfully ignorant of the nature of the input device. When the application has something to send out, it sends it out through a port to an adapter, which creates the appropriate signals needed by the receiving technology (human or automated). The application has a semantically sound interaction with the adapters on all sides of it, without actually knowing the nature of the things on the other side of the adapters.
This inspired: JavaScript non-framework called http://hexagonaljs.com/. It's so easy to extract GuiAdapter and StorageAdapter, leaving the middle hex boundary-unaware.
CQRS Pattern
Golden Master Pattern
http://blog.adrianbolboaca.ro/2014/05/legacy-coderetreat-golden-master/
For all the given situations we need to think if the system tests generated with the Golden Master are enough, or we need to start adding other types of tests like unit tests, component tests, integration tests, security tests, etc.
The Golden Master technique is based on the following steps:
Find the way the system delivers its outputs
Check for clear outputs of the system: console, data layer, logger, file system, etc.
For all the given situations we need to think if the system tests generated with the Golden Master are enough, or we need to start adding other types of tests like unit tests, component tests, integration tests, security tests, etc.
The Golden Master technique is based on the following steps:
Find the way the system delivers its outputs
Check for clear outputs of the system: console, data layer, logger, file system, etc.
Find a way to capture the output of the system without changing the production code
Think if that output can be “stolen” without changing the production code. For example you could “steal” the console output by redirecting the stream of the console to an in-memory stream. Another example would be injecting an implementation of a data layer interface that would write to another data source than the production code would.
Find a pattern of the outputs
The output of the system could be text or a data structures tree or another type of stream. Starting from this output type you can decide if you could go on to the next step.
Generate enough random inputs and persist the tuple input/output
In the case you can persist the outputs to a simple data repository, you can think about what are the inputs for the corresponding outputs. Here the magic consists in finding a good balance of random or pseudo-random inputs. We need inputs that would cover most of the system with tests, but in the same time the test would run in seconds. For example in the case of a text generating algorithm we need to decide if we want to feed the system with 1000 or one million entry data. Maybe 10 000 input data are enough. We will anyway check the tests coverage during the last stage.
We need to persist the pair input-output. The output would be the Golden Master, the reference data we will always check our SUT against.
Write a system test to check the SUT against the previously persisted data
Now that we have a way to “steal” the outputs and we have a guess about how to generate enough input-output pairs, but not to many, we can call the system and check it against the outputs for a given input. We need to check if the test touches the SUT and if it passes. We also need to check that the test runs fast enough, in seconds.
Commit the test
Always when a green test passes we need to commit the code to a local source control system. Why? So that we can easily revert to a stable testable system.
Important: Do not forget to commit also the golden masters (files, database, etc)!
Check test behaviour and coverage
Hexagonal Architecture (http://alistair.cockburn.us/Hexagonal+architecture)
Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases.
As events arrive from the outside world at a port, a technology-specific adapter converts it into a usable procedure call or message and passes it to the application. The application is blissfully ignorant of the nature of the input device. When the application has something to send out, it sends it out through a port to an adapter, which creates the appropriate signals needed by the receiving technology (human or automated). The application has a semantically sound interaction with the adapters on all sides of it, without actually knowing the nature of the things on the other side of the adapters.
This inspired: JavaScript non-framework called http://hexagonaljs.com/. It's so easy to extract GuiAdapter and StorageAdapter, leaving the middle hex boundary-unaware.
CQRS Pattern
Command Query Responsibility Segregation built on Alistair's Hexagonal Architecture by Greg Young. http://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf
Here is Alistair describing it: http://www.slashdotdash.net/2010/09/27/alistair-cockburns-lightning-talk-on-cqrs-recorded-at-the-mountain-west-ruby-conference-2010/
Here is Alistair describing it: http://www.slashdotdash.net/2010/09/27/alistair-cockburns-lightning-talk-on-cqrs-recorded-at-the-mountain-west-ruby-conference-2010/
No comments:
Post a Comment