Behaviors Tested

The unittests in this project are documented using Gherkin Syntax according to Behavior Driven Development practices. The features tested by this project are described comprehensively.

Feature: Parts are selected based on fields on a Bill of Materials

Scenario: Parts are selected by the “Value” and “Footprint” BOM fields

GIVEN a BOM row references a value and symbol which describes more than one part in the catalog

WHEN _get_matching_parts is called for the given BOM row

THEN all catalog parts which match the value and symbol will be returned

Scenario: When a BOM row matches more than one Part, the deprioritized Part will not be preferred

GIVEN a BOM row references a value and symbol which describes more than one part in the catalog

AND any of the parts are marked is_deprioritized

WHEN _get_matching_parts is called for the given BOM row

THEN no parts marked is_deprioritized will be returned

AND all other catalog parts which match the value and symbol will be returned

Scenario: Parts are not selected if they do not match both “Value” and “Footprint” BOM rows

GIVEN a BOM row references a symbol which describes more than one part in the catalog

AND the BOM row references a value which describes more than one part in the catalog

WHEN _get_matching_parts is called for the given BOM row

THEN all catalog parts which match the value and symbol will be returned

AND any catalog partch which do not match the value or symbol will not be returned

Scenario: When a BOM row matches more than one Part, the Part with the lowest stock will be preferred

GIVEN a BOM row references a value and symbol which describes more than one part in the catalog

AND the parts are in stock

WHEN _get_matching_parts is called for the given BOM row

THEN all catalog parts which match the value and symbol will be returned

AND the parts will be returned sorted descending by the quantity in stock

Scenario: BOM rows without “Vendor” or “PartNum” fields and which do not match any Parts by “Value” and “Footprint” fields will not match to any Part

GIVEN a BOM row does not reference either a vendor or a part number

AND th BOM row references a value and symbol which describes no part in the catalog

WHEN _get_part is run for that BOM row

THEN _get_matching_parts is run for that BOM row

AND null is returned

Scenario: BOM rows without “Vendor” or “PartNum” fields will be matched to Parts by “Value” and “Footprint” fields

GIVEN a BOM row does not reference either a vendor or a part number

AND the BOM row references a value and symbol which describes at least one part in the catalog

WHEN _get_part is run for that BOM row

THEN _get_matching_parts is run for that BOM row

AND the first result is returned

Scenario: “Vendor” and “PartNum” fields on BOM rows will resolve to a single Vendor Part

GIVEN a BOM row does reference a vendor and part number

WHEN _get_part is run for that BOM row

THEN _get_vendor_part is run for that BOM row

AND the first result is returned

Scenario: “Vendor” and “PartNum” fields on BOM rows which do not resolve to a single part will raise an exception

GIVEN a BOM row does reference a vendor and part number

AND the part number is not represented by a vendor part

WHEN _get_part is run for that BOM row

THEN _get_vendor_part is run for that BOM row

AND a MissingVendorPart exception is raised

Scenario: “Vendor” and “PartNum” BOM fields will be used to find Parts

GIVEN a BOM row references a known vendor part by matching the columns for “Vendor” and “PartNum”

WHEN _get_vendor_part is run for that BOM rown

THEN the known vendor part will be returned

Scenario: Unknown “PartNum” BOM fields will raise exceptions unless the “Vendor” is API enabled

GIVEN a BOM row references an unknown “PartNum”

AND the “Vendor” for the BOM row is not “Mouser”

WHEN _get_vendor_part is run for that BOM rown

THEN a MissingVendorPart exception is raised

Scenario: Parts and Vendor Parts will be created and autopopulated for BOM rows with unknown “PartNum” and the “Vendor” is “Mouser”

GIVEN a BOM row references an unknown vendor part

AND the “Vendor” for the BOM row is “Mouser”

WHEN _get_vendor_part is run for that BOM rown

THEN the process to create a placeholder vendor part and populate it with real data is initiated

AND the placeholder part is returned

Feature: Bills of Material are Synced to Project Versions yielding Project Parts, and this process can be repeated as needed

Scenario: Bills of Material will be retrieved (http) and parsed into Project Parts

GIVEN a BOM has been synced yielding project parts

AND the BOM has been altered such that there are now fewer rows

WHEN _sync is run for the BOM

THEN _sync_row will be run for each row of the BOM

AND any project parts associated with a row removed from the BOM will be deleted

AND any project parts associated with a retained row from the BOM will be retained

AND the commit hash of the BOM will be saved on the project version

Scenario: Only valid commit refs will be synced

GIVEN a commit ref cannot be found in the project repo

WHEN sync is run for the project

THEN _sync will not be run

Scenario: When resyncing a Bill of Materials Project Parts which are not longer represented on the BOM will be deleted and new Project Parts will be created as needed to represent the BOM

GIVEN a BOM for a project version has not been synced

AND project parts exist for that project version anyhow

AND the BOM calls for a part which does not exist

WHEN _sync is run for the BOM

THEN _sync_row will be run for each row of the BOM

AND any project parts which are not associatew with a BOM row will be deleted

AND project parts will be created for each row in the BOM

AND project parts created without a matching part will have a missing part description with all details from the BOM row

AND the commit hash of the BOM will be saved on the project version

Scenario: Footprint Refs for components will update as the BOM goes through revisions by resyncing the Project Version

GIVEN a project_part exists which is associated with outdated footprint refs

WHEN _sync_footprints is run for the project part providing new footprint refs

THEN existing footprint references which were not provided will be deleted

AND existing footprint references which are provided will be retained

AND non-existing footprint references whic are provided will be created

Scenario: Implicit Project Parts will be created whenever a BOM which uses a Package with implicit parts is synced, and the quanitities will be appropriate

GIVEN a project part references a part

AND the given part’s package is associated with an ImplicitProjectPart

WHEN _sync_implicit_parts is run for the project part

THEN a project part is created for the ImplicitProjectPart

AND the created project part references an appropriate quantity of parts

AND the created project part has the same line number as the given project part

Scenario: Implicit Project Parts will remain unchanged when a BOM is re-synced with changes to other rows

GIVEN a BOM has been synced yielding a project part

AND the project part has associated implicit project part instances

AND the ImplicitProjectPart definitions have not changed

WHEN _sync_implicit_parts is run for the yielded project part

THEN the existing implicit part instances will not be altered

AND no new implicit part instances will be created

Scenario: Implicit Project Parts will be deleted and recreated when a BOM is re-synced which changes which Packages are use

GIVEN a BOM has been synced yielding a project part

AND the project part has an associated implicit project part instance

AND the ImplicitProjectPart definition has changed such that the aforementioned project part instance is no longer representing the correct part

WHEN _sync_implicit_parts is run for the yielded project part

THEN the old implicit part instance will be deleted

AND a new implicit part instance reflecting the correct part will be created

Scenario: Implicit Project Parts with separate owners will not result in Project Parts

GIVEN a project part references a part

AND the given part’s package is associated with an ImplicitProjectPart

AND the associated ImplicitProjectPart has a separate owner

WHEN _sync_implicit_parts is run for the project part

THEN no implicit project part is created

Scenario: Implicit Project Parts will be updated when a BOM is re-synced which changes the quantity of components required

GIVEN a BOM has been synced yielding a project part

AND the project part has an associated implicit project part instance

AND the ImplicitProjectPart definitions has changed such that the quantity of implicit parts called for is different

WHEN _sync_implicit_parts is run for the yielded project part

THEN the old implicit part instance will be altered to reflect the updated quantity

Scenario: Syncing a row from a Bill of Materials will result in a Project Part with matching Value and Footprint (or vendor and part number), quantity and footprints will also be reproduced

GIVEN a valid BOM row exists for a project version

AND there exists at least one part which will match the attributes of the BOM row

WHEN _sync_row is run for the BOM row

THEN a project part will be returned

AND the project part will reference the aforementioned project version

AND the project part will reference an a part with matching “Value” and reference symbol

AND the project part will show the correct part quantity for the project version

AND the project part will reference the footprint references from the BOM row

Scenario: Syncing a row from a Bill of Materials with a Vendor (other than “Mouser”) and PartNum will result in a Project Part with a missing part description when an appropriate Part cannot be found in the system.

GIVEN a valid BOM row exists for a project version

AND the BOM row provides a vendor and part number

AND the vendor is not Mouser

AND there does not exist any part which will match the attributes of the BOM row

WHEN _sync_row is run for the BOM row

THEN a project part will be returned

AND the project part will reference the aforementioned project version

AND the project part will have a missing part description which possesses the information in the BOM row

AND the project part will not have a reference to a part

Feature: Part Satisfaction is responsive to stock of Parts

Scenario: Parts marked equivalent to each other will be found to an arbitrary recursive depth

GIVEN there is a branching tree of parts equivalent to a certain part

WHEN the part satisfaction manager looks for equivalent parts

THEN the equivalent parts will be found to a configurable max depth

Scenario: Part Satisfaction indicates insufficient stock for Project Parts

GIVEN a part exists

AND the given part has an inventory line with insufficient stock

WHEN the part satisfaction ensure reservation process is run targeting that part

THEN the inventory line is used for fulfillment

AND an InsufficientInventory exception will be raised with the unfilfilled need

AND no reservation will be created

AND no inventory action will be created

Scenario: Part Satisfaction indicates missing stock for Project Parts

GIVEN a part exists

AND there is no inventory line for the part

WHEN the part satisfaction ensure reservation process is run targeting that part

THEN no inventory line will be used in fulfillment

AND an InsufficientInventory exception will be raised with the unfilfilled need

Scenario: Part Satisfaction only considers Inventories owned by Project owner

GIVEN a part exists

AND the given part has an inventory line with sufficient stock with separate owner

WHEN the part satisfaction ensure reservation process is run targeting that part

THEN the inventory line is not used for fulfillment

AND an InsufficientInventory exception will be raised with the unfilfilled need

AND no reservation will be created

AND no inventory action will be created

Scenario: Part Satisfaction indicates sufficient stock for Project Parts

GIVEN a part exists

AND the given part has two inventory lines with stock

WHEN the part satisfaction ensure reservation process is run targeting the part

THEN the inventory line with the least stock is selected for inventory action

Scenario: Part Satisfaction will respect (de-)prioritization

GIVEN a part exists

AND the given part has a deprioritized inventory line with stock

AND the given part has an inventory line with stock

WHEN the part satisfaction ensure reservation process is run

THEN the non deprioritized inventory line will be used

Scenario: Part Satisfaction will utilize stock from more than one Inventory Line

GIVEN a part exists

AND the given part has more than one inventory line with stock

AND one of the inventory lines does not have enough stock for the project

WHEN the part satisfaction ensure reservation process is run targeting the part

THEN the inventory line with the least stock is used for fulfillment first

AND the inventory line with the next least stock is used for the remainder

Scenario: Part Satisfaction will return stock to more than one Inventory Line

GIVEN a project build part reservation exists

AND the given reservation has more than one inventory action associated

AND the number of needed parts has been reduced for the build

WHEN the part satisfaction ensure reservation process is run targeting the part

THEN the inventory action for the inventory line with the most remaining stock will be refunded

AND the inventory action for the inventory line with the next most remaining stock will be refunded (and so on)

AND in the case of ties, the inventory action with the largest delta will be refunded

Feature: Incomplete Project Builds can be cancelled

Scenario: Cancelling a Project Build will remove reservations, free stock, and un-clear the Project Build

GIVEN part reservations exist for a project build

WHEN the cancel build action is run for the project build

THEN the part reservations are deleted

AND the inventory lines are credited with the reservation quantities

AND the project build clear status is cleared

Scenario: Cancelling a completed Project Build will do nothing

GIVEN a project build has been completed

WHEN the cancel build action is run for the project build

THEN the project build completed status will be unchanged

Scenario: Cancel Build Wrapper calls Cancel Build Process

WHEN the cancel build wrapper is called for a project build

THEN the cancel build process is called for the project build

Feature: Project Builds will be Cleared when sufficient stock of Parts are reserved to cover all Project Parts

Scenario: Inventory contains reserves stock to complete a Project Build

GIVEN a part is used in a project

AND there is enough stock of the given part to complete the project

WHEN the project clear to build process is run

THEN the project will be marked as cleared

AND a reservation will be made for all the quantity of parts needed

AND the quantity of the parts will be deducted from the inventory for the part

Scenario: Clear To Build Process combines like Project Parts when reserving Parts

GIVEN a the same part is used as two separate project parts

WHEN the project clear to build process is run

THEN only one reservation for the part will be created

AND the full quantity of parts will be reserved

Scenario: Clear To Build Process will fall back to equivalent Parts

GIVEN a project uses a part which is not stocked

AND the given part is equivalent_to another part which is stocked

WHEN the project clear to build process is run

THEN the other part will be reserved

Scenario: Clear To Build Process will prefer original Parts over equivalents

GIVEN a project uses a part which is stocked

AND the given part is equivalent_to another part which is stocked

WHEN the project clear to build process is run

THEN the original part will be reserved

Scenario: Clear To Build Process will utilize equivalents to substitute Parts

GIVEN a project uses a part which is stocked

AND the project part includes a substitute_part which is not stocked

AND the substitute part is equivalent_to another part which is stocked

WHEN the project clear to build process is run

THEN the equivalent part will be reserved

Scenario: Clear To Build Process ignores excluded Project Parts

GIVEN a project build marks a given part as exluded

WHEN the project clear to build process is run

THEN no reservation is made for the excluded part

Scenario: Clear To Build Process will utilize fallback parts for Project Builds to overcome shortage

GIVEN a project uses a part with insufficient stock

AND the project clear to build process has been run

AND the project build part shortage has been updated to have a fallback part

AND the fallback part has stock

WHEN the project clear to build process is re-run

THEN all the stock of the given part will be reserved

AND the fallback part will be reserved to cover the remaining need

AND subsequent runs of the project clear to build process will succeed

Scenario: Clear To Build Process will not duplicate reservations upon additional executions

GIVEN a project build has been cleared

WHEN the project clear to build process is run

THEN no new reservations will be created

AND no new inventory actions will be created

AND no inventory lines will be altered

Scenario: Clear To Build Process will add new reservations on subsequent executions when a part is added newly

GIVEN a project build has been cleared

AND a project part has been added to the project version

WHEN the project clear to build process is run

THEN a reservation for the added project part will be created

AND an inventory action for the created reservation will be created

AND the inventory line will be debited

AND no other inventory actions will be created

AND no other inventory lines will be altered

Scenario: Clear To Build Process will not duplicate shortages upon additional executions

GIVEN a project build has been cleared

AND shortages were found

AND shortages still exist

WHEN the project clear to build process is run

THEN no new shortages will be created

AND no new inventory actions will be created

AND no inventory lines will be altered

Scenario: Clear To Build Process will delete shortages and create reservations upon additional executions when stock has been added

GIVEN a project build has been cleared

AND shortages were found

AND shortages no longer exist

WHEN the project clear to build process is run

THEN no new shortages will be deleted

AND reservations will be created

AND inventory actions will be created

AND inventory lines will be altered

Scenario: Clear To Build Process will remove reservations on subsequent executions when the part is no longer needed

GIVEN a project build has been cleared

AND a project part has been removed from the project version

WHEN the project clear to build process is run

THEN the reservation for the removed project part will be deleted

AND the inventory action for the deleted reservation will be deleted

AND the inventory line will be credited

AND no other inventory actions will be created

AND no other inventory lines will be altered

Scenario: Inventory lacks sufficient stock to complete a Project Build

GIVEN a part is used in a project

AND there is not enough stock of the given part to complete the project

WHEN the project clear to build process is run

THEN the project will not be marked clear to build

AND the part and quantity of shortfall will be persisted

Scenario: Clear To Build Process will not use original Part when substitute Part is named

GIVEN a project uses a part which is stocked

AND the project part includes a substitute_part which is stocked

WHEN the project clear to build process is run

THEN the other part will be reserved

Scenario: Clear To Build Process will log a shortfall when substitute Part is not stocked (even when original part is stocked)

GIVEN a project uses a part which is stocked

AND the project part includes a substitute_part which is not stocked

WHEN the project clear to build process is run

THEN no part will be reserved

AND a shortfall will be created

Scenario: Clear To Build Wrapper ignores non-extant Project Builds

GIVEN a project build exists

AND the given project build has been completed

WHEN the clear to build wrapper is called for the given project build

THEN an exception is raised

Scenario: Clear To Build Wrapper calls Clear To Build Process for Project Builds

GIVEN a project build exists

WHEN the clear to build wrapper is called for the given project build

THEN the clear to build process is called for the given project build

Feature: Project Builds can be completed

Scenario: Cleared Project Build can be completed and Part Reservations will be utilized

GIVEN a project build has been cleared

AND part reservations made

WHEN the complete build action is run for the project build

THEN the project build is marked completed

AND the part reservations are marked utilized

Scenario: An already completed Project Build cannot be completed again

GIVEN a project build is marked completed

WHEN the complete build action is run for the project build

THEN no operation is run on the project build

Scenario: Project Build must be cleared before it can be completed

GIVEN a project build has not been cleared

AND there is not sufficient inventory to build the project

WHEN the complete build action is run for the project build

THEN the clear to build action is run for the project build

AND the project is not marked completed

Scenario: Complete Build Wrapper raises for non-extant Project Build

WHEN the complete build action is called for a non existent project build

THEN an exception is raised

Scenario: Complete Build Wrapper calls Complete Build Process

WHEN the complete build wrapper is called for a cleared project build

THEN the complete build process is called for the project build

Feature: Vendor Orders can be generated and fulfilled

Scenario: Project Build Shortfalls will be binned by Part

GIVEN a project build exists

AND the project build has several shortfalls

WHEN _accumulate_shortfalls is called for the project build

THEN any shortfalls which share a common part will be gathered into a single entry with the sum total of component count

AND all shortfalls from the build will be represented in the return

Scenario: Complete Vendor Order Process will complete each Order Line and fulfill the Vendor Order

GIVEN a vendor order exists with several order lines

WHEN _complete_order is called on the vendor order

THEN _complete_order_line will be called for each order line

AND the vendor order will be marked “fulfilled”

Scenario: Completing an Order Line will create Inventory Line if necessary and create an Inventory Action

GIVEN a vendor order has an order line associated to an inventory

AND no inventory line exists for the order line part

WHEN _complete_order_line is run

THEN an inventory line will be created in the given inventory for the order line part

AND the quantity of parts in the inventory line will be increased by the quantity in the inventory line

AND an inventory line action will be created showing the inventory line, the change in quantity, and the vendor order which generated the action

Scenario: Complete Order Line Process will update an Inventory Line and create an Inventory Action

GIVEN a vendor order has an order line

AND an inventory line exists for the order line part

WHEN _complete_order_line is run

AND the quantity of parts in the inventory line will be increased by the quantity in the inventory line

AND an inventory line action will be created showing the inventory line, the change in quantity, and the vendor order which generated the action

Scenario: Populate Vendor Order Process will add to an existing Order Line if one exists for a Part

GIVEN a vendor part exists for a vendor

AND a vendor order exists for the given vendor

AND a vendor order line exists for the part

WHEN _populate_vendor_order is called for the vendor part providing a quantity

THEN the provided quantity will be added to the existing order line

Scenario: Populate Vendor Order Process will create a new Order Line in an existing Vendor Order as needed.

GIVEN a vendor part exists for a vendor

AND a vendor order exists for the given vendor

AND no vendor order line exists for the part

WHEN _populate_vendor_order is called for the vendor part providing a quantity

THEN a vendor order will be created with the given vendor

AND a vendor order line will be created for the vendor part

AND the provided quantity will be represented in the order line

Scenario: Populate Vendor Order Process will create a new Vendor Order when no open Vendor Order exists.

GIVEN a vendor part exists for a vendor

AND no vendor order exists for the given vendor

WHEN _populate_vendor_order is called for the vendor part providing a quantity

THEN a vendor order will be created with the given vendor

AND a vendor order line will be created for the vendor part

AND the provided quantity will be represented in the order line

Scenario: Populate Vendor Order Process will create a new Vendor Order when no open Vendor Order exists.

GIVEN a vendor part exists for a vendor

AND there is an owner

AND a vendor order exists for the given vendor with a separate owner

WHEN _populate_vendor_order is called for the vendor part providing a quantity

THEN a vendor order will be created with the given vendor and the given owner

AND a vendor order line will be created for the vendor part

AND the provided quantity will be represented in the order line

Scenario: Select Vendor Part Process prefers the cheapest Vendor for the given Part

GIVEN a part exists with more than one vendor part

WHEN _select_vendor_part is run for the part

THEN the vendor part with the lowest cost will be returned

Scenario: Select Vendor Part Process raises when it finds no Part

GIVEN a part exists with no vendor part

WHEN _select_vendor_part is run for the part

THEN a MissingVendorPart exception is raised

Scenario: Complete Vendor Order Wrapper Completes only existing Vendor Orders

GIVEN a vendor order exists

WHEN complete_order is called for the vendor order

THEN _complete_order is called for the vendor order

Scenario: Complete Vendor Order Wrapper raises error for non-extant Vendor Orders

WHEN complete_order is called for a non-extant vendor order

THEN an exception is raised

Scenario: Complete Vendor Order Wrapper raises error for already fulfilled Vendor Orders

GIVEN a vendor order exists which has already been fulfilled

WHEN complete_order is called for the vendor order

THEN an exception is raised

Scenario: Generate Vendor Orders Process will create Vendor Orders and Order Lines to satisfy any Shortfalls for a Project Build

GIVEN a project build exists

AND the project build has several shortfalls to several vendors

AND the project build has shortfalls for parts with no vendor

WHEN generate_vendor_orders is called for the project build

THEN vendor orders will be made to the several vendors

AND each vendor order will have lines for the parts from that vendor

AND shortfalls without a vendor will be ignored

Scenario: Generate Vendor Orders Proces will ignore non-extand Project Builds

WHEN generate_vendor_orders is called for a non-extant project build

THEN no vendor orders are generated

Scenario: Generate Vendor Orders Process will utilize the same Owner for creating Vendor Orders as the Project Build Owner

GIVEN a project build exists with a separate owner

AND shortages exist for that project build

AND two owners have their own inventories

WHEN generate_vendor_orders is called for the project build

THEN a vendor order owned by the separate owner will be created

Feature: Parts appearing on BOMs with Vendor “Mouser” will be autopopulated with data from the Mouser API

Scenario: Footprints listed in the BOM will be used

GIVEN a project version BOM row represents a known footprint

AND the same row shows the vendor as “Mouser”

WHEN _get_footprint is run for the BOM row

THEN the known footprint is returned

Scenario: Footprints listed in “Mouser” BOM rows will be created if necessary

GIVEN a project version BOM row represents an unknown footprint

AND the same row shows the vendor as “Mouser”

WHEN _get_footprint is run for the BOM row

THEN a new footprint matching the unknown footprint is created and returned

Scenario: Footprints imply a component Package

GIVEN a project version BOM row represents a known footprint

AND the same row shows the vendor as “Mouser”

AND the known footprint has an associated package

WHEN _get_package is run for the BOM row

THEN the package for the known footprint is returned

Scenario: Placeholder Packages will be created as necessary with ambigious default field values

GIVEN a project version BOM row represents an unknown footprint

AND the same row shows the vendor as “Mouser”

WHEN _get_package is run for the BOM row

THEN a package (with unknown technology) is created and returned returned

Scenario: Parts represented on “Mouser” BOM rows will resolve to known Parts

GIVEN a project version BOM row represents a known part

AND the same row shows the vendor as “Mouser”

WHEN _get_part is run for the BOM row

THEN the known part is returned

Scenario: Parts represented on “Mouser” BOM rows will be created in the system when they are previously unknown

GIVEN a project version BOM row represents an unknown part

AND the same row shows the vendor as “Mouser”

AND the BOM row component package (gleaned from the BOM footprint) is known

WHEN _get_part is run for the BOM row

THEN a placeholder part is created which matches the BOM row

AND the created part references the appropriate component package

Scenario: Parts represented on “Mouser” BOM rows will be represented with Parts and Vendor Parts which are autopopulated

GIVEN a project version BOM row represents an unknown part

AND the same row shows the vendor as “Mouser”

AND the BOM row component package (gleaned from the BOM footprint) is known

WHEN create_vendor_part is run for the BOM row

THEN a placeholder part is created which matches the BOM row

AND the created part references the appropriate component package

AND a vendor part is created which references the “PartNum” of the BOM row

AND a task to populate the vendor part with actual data will be started

Feature: Projects hosted on Github will have commit-level traceability of commit references

Scenario: Commit hashes will be found when requesting branches

GIVEN a branch exists in github

WHEN _get_branch_head_commit_hash is called with the branch name

THEN the commit hash will be returned

Scenario: Non hash commit refs will not be found by requesting commits

GIVEN a branch exists in github

WHEN _get_branch_head_commit_hash is called with something other than the branch name

THEN an exception will be raised

Scenario: Commit hashes will be found when requesting commits

GIVEN a commit hash exists in github

WHEN _get_commit_hash is called with the commit hash

THEN the commit hash will be returned

Scenario: Non hash commit refs will not be found by requesting commits

GIVEN a commit hash exists in github

WHEN _get_commit_hash is called with something other than the commit hash

THEN an exception will be raised

Scenario: Commit hashes will be found when requesting tags

GIVEN a tag exists in github

WHEN _get_tag_commit_hash is called with the tag name

THEN the commit hash will be returned

Scenario: Non hash commit refs will not be found by requesting commits

GIVEN a tag does not exists in github

WHEN _get_tag_commit_hash is called with something other than the tag name

THEN an exception will be raised

Feature: Bills of Material will be parsed into a format consistent with inventory conventions

Scenario: Component values will be converted to decimal notation and SI prefixes less than 1 will be lower-cased

GIVEN a component value in a project version BOM is in the format 2U2

AND the SI prefix is less than 1

WHEN the BOM is synced

THEN the component value will be normalized to 2.2u

AND the SI prefix will be lower case

Scenario: Component values will be converted to decimal notation and SI prefixes greater than 1 will be capitalized

GIVEN a component value in a project version BOM is in the format 2K2

AND the SI prefix is greater than 1

WHEN the BOM is synced

THEN the component value will be normalized to 2.2K

AND the SI prefix will be capitalized

Scenario: Component values for diodes will not be altered

GIVEN a component value in a project version BOM is in the format 1N4148

WHEN the BOM is synced

THEN the component value will not be altered

Scenario: Extra columns in BOM will be silently ignored

GIVEN there are unknown columns in the BOM

WHEN the BOM is synced

THEN the unknown columns are silently ignored

Feature: Inventory Lines accurately represent stock and facilitate reorder

Scenario: Inventory Lines will prominently display Vendor Part item numbers with which they share a Part

GIVEN an inventory line represents a part with at least one vendor part

WHEN the item numbers are gotten from the inventory line

THEN all vendor part item numbers will be represented

AND other vendor part item numbers will not be represented

Scenario: The stock of Parts on-hand, including quantities from unutilized Reservations will be visible

GIVEN an inventory line with positive quantity

AND some number of “order” inventory actions associated to the given inventory line

AND some number of “build” inventory actions associated to the given inventory line for which the build is not cleared

AND some number of “build” inventory actions associated to the given inventory line for which the build is cleared

AND some number of “build” inventory actions associated to the given inventory line for which the build is completed

WHEN the on hand count is gotten from the given inventory line

THEN the number will be the positive quanity on the inventory line less the quanitiy indicated by all build actions which are not completed

Feature: Project Build Part Reservations may encapsulate several Inventory Actions and Project Parts

Scenario: Footprint Refs are reproduced from BOM Row to Project Build Part Reservations via Project Part

GIVEN an project part represents a BOM row with at least one footprint reference

AND another project part with matching part has some other footprint

AND the second project part is optional

AND both project parts are associated to a build reservation

WHEN the footprints are gotten from the build reservation

THEN all footprint refs from the BOM row will be represented

AND all footprint refs from the second BOM row will be represented

AND the second BOM row footprint refs will be marked with asterices (*)

Scenario: Reservations show full quantity of parts reserved

GIVEN a reservation represents more than one inventory action

WHEN the reservation quantity is retrieved

THEN all inventory action deltas will be represented in the return

Scenario: Footprint Refs are reproduced from BOM Rows to Part Reservation

GIVEN an project part represents a BOM row

AND another project part with identical part represents another BOM row

AND both project parts are associated to a build reservation

WHEN the line numbers are gotten from the build reservation

THEN line numbers for both BOM rows will be represented

AND other line numbers will not be represented

Feature: Project Parts represent data from a Bill of Materials

Scenario: Footprint Refs are reproduced from BOM Row to Project Part

GIVEN an project part represents a BOM row with at least one footprint reference

WHEN the footprints are gotten from the project part

THEN all footprint refs from the BOM row will be represented

AND other footprint refs will not be represented

Feature: Project Versions map to a git respository and commit

Scenario: Project Version Bills of Material will be found from Project and Project Version attributes

GIVEN a project and project version exist

AND these are correctly configured

WHEN bom_url is called for that project version

THEN a valid URL is returned