---
# System prepended metadata

title: Paketo Buildpackage testing

---

# Paketo Buildpackage testing

### Basics
- We don't want to re-do all the testing we did in implementation buildpacks, we are not testing buildpack features only that detection in the`order` we outline is valid.
- Maybe we don't need to fully commit to any of these right now given we are just worried about `node` `php` and `go` and `dotnet`

### Strategies:
Lets consider a 'future' Ruby CNB with the following `buildpack.toml`

```
[[order]]

  [[order.group]]
    id = "mri"

  [[order.group]]
    id = "bundler"
    
  [[order.group]]
    id = "bundler-install"

  [[order.group]]
    id = "ruby-server"

  [[order.group]]
    id = "web-framework1"
    optional = true
    
  [[order.group]]
    id = "web-framework2"
    optional = true
    
  [[order.group]]
    id = "web-framework3"
    optional = true
    
[[order]]
  [[order.group]]
    id = "jruby"

  [[order.group]]
    id = "bundler"
    
  [[order.group]]
    id = "bundler-install"

  [[order.group]]
    id = "ruby-server"

  [[order.group]]
    id = "web-framework1"
    optional = true
    
  [[order.group]]
    id = "web-framework2"
    optional = true
    
  [[order.group]]
    id = "web-framework3"
    optional = true
```

The buildpackage that will result from this `buildpack.toml` has multiple buildpacks that provide `ruby` and multiple buildpacks that end the group. 

So a single `pack build` will give us a path through the `buildpack.toml` 
- Ex: `mri, bundler, bundler-install, ruby-server, web-framework1`

This gives us a couple stragies to test these buildpacks.

#### Gotta test em all
Test all paths through the buildpack. Probably a bad idea...

Resulting paths from above:

- mri | bundler | bundler-install | ruby-server
- mri | bundler | bundler-install | ruby-server | web-framework-1
- mri | bundler | bundler-install | ruby-server | web-framework-2
- ... 
- No

#### Test each buildpack at least once
Basic idea is that we want at least one end to end to include each buildpack.
Gives us a stronger guarentee that our buildpacks work correctly

Resulting tests from this strategy:

- mri | bundler | bundler-install | ruby-server | web-framework-1
- jruby | bundler | bundler-install | ruby-server | web-framework-2
- mri | bundler | bundler-install | ruby-server | web-framework-3

#### Test a single `pack` path through an order group
This is the least rigourous. Pushes most testing responsibility onto the buildpacks themselves.
We only need a single test for each order group to make sure that it is reachable. Assume
that all buildpacks in a group have been tested.
- (+) minimum number of tests
- (-) requires a implementation buildpack to be responsible for testing all possible pack paths 
      that end with it.

Resulting tets from this strategy:

- mri | bundler | bundler-install | ruby-server | web-framework-1
- jruby | bundler | bundler-install | ruby-server | web-framework-2

