@ justfewtuts.blogspot.in [31/May/2013]
…..That’s the shift. The logic developed for Infrastructure acts as a glue to all other applications created in house and 3rd party. Here in Infrastructure feature development there is more to test for the effect it has on the it’s users (software/hardware) and less on internal changes (dependencies and dynamic content). Now the stuff in parentheses here means a lot more than seems… let’s get into detail of it.
Real usability of Testing is based on keeping sanctity of WHAT needs to be tested WHERE.
- in-house ‘Product’, that is the central component you are developing
- 3rd Party services it collaborates with,
- external services it utilizes for what it doesn’t host,
- operating system that it supports and Ops-knows what not.
- Resources/Dependencies getting called in right order and grouped for specific state.
- It also relates to correct generation/purging of dynamic content, that content can itself range as
- non-corrupt configuration files generated of a template
- format of sent configuration data from one Infra-component to another for reflected changes
- dynamically creating/destroying service instances in case of auto-scalable infrastructure