Articles in the category "Test Kitchen"

Going beyond the easier use case of mocking attributes and databags, we sometimes want to fake some data about the system itself.

The more complex your cookbooks, the bigger the need to supply some external information to your test machines. Passing specific attributes, values of databags or secrets for testing become necessary. We will go through these use cases and show how to mock the data in this post.

It is surprising how many resources on the Internet are carrying on outdated or deprecated information - the Chef ecosystem is no exception to this. While outdated style in Ruby files has been detected via cookstyle for a while, Test Kitchen files still have no sanity checks yet. Let’s see what changed in this short post.

Testing on Physical Machines - Part 2 After introducing how to work with physical machines and Test Kitchen last time, we will look at a feature to allow central orchestration of available machines.

Testing on Physical Machines with kitchen-static This article shows how to work with Test Kitchen on physical machines using the kitchen-static Driver. If you need to deliver a product (bundle of server and software) instead of just configuration, some tasks cannot be run on virtual machines alone but need testing on actual hardware.

Instant Clones with kitchen-vcenter Over the last few posts we optimized our kitchen-vcenter setups and are stuck with the usual, long boot times of Windows systems. Surprisingly, VMware introduced a feature which can help us get rid of those. For good.

Guest Operations and kitchen-vcenter In this part of the blog series, we will look on how to speed up IP discovery of new machines with a little-known feature of the VMware Tools.

Linked Clones with kitchen-vcenter Quickly starting new Test Kitchen machines is one of the main concerns for getting the desired feedback cycles in cookbook development. While machines get created as a full clone by default, the kitchen-vcenter driver offers a better alternative.