tests/testthat/test-get_excel_data.R

test_sheet <- function(fname) testthat::test_path("sheets", fname)

test_that("get_excel_data handles default arguments well", {
  data <- get_excel_data(test_path("testdata", "sample_tom_data.xlsx"), "Practices Areas") %>%
    janitor::clean_names()

  expect_equal(data$summary, "Requirements Analysis and Design Definition are the activities that BAs perform to structure and organize requirements after elicitation. This is used by BAs to define and guide change. The activities are instrumental in performing a thorough analysis and communicating with stakeholders.\r\n\r\nThe large box is referred to as the \"practice area\" and the small boxes within the practice area are referred to as \"activites\". The practice area and activities are typically conducted iteratively and can be conducted in parallel or separately. It is important to note, the prevailing standard in TS is to use the REQM process with JIRA for Requirements Management.")
  expect_equal(data$activities, "Requirements Analysis and Design Definition practice area has six activities:\r\nSpecify & Model Requirements activity analyzes, synthesizes, and refines the elicitation results into requirements and designs using analytical techniques.\r\nVerify Requirements activity ensures the requirements are designed with enough detail to be usable by a particular stakeholder. Each requirement must be consistent and high quality and the activity verifies all the requirements meet this standard.\r\nValidate Requirements activity ensures the set of requirements deliver business value and supports the goals and objectives holistically. This is an on-going process to ensure the stakeholder requirements don't conflict and if they do conflict this is exposed and resolved.\r\nDefine Requirements Architecture activity structures all the requirements so they support the overall business purpose for the change. The requirements must work effectively as a cohesive whole and achieve the desired end-state. The goal of this activity is to identify gaps.\r\nDefine Design Options activity identifies, explores and describes the different ways of meeting the needs. This activity answers the question \"What options do I have to meet the future-state?\".\r\nAnalyze Potential Value and Recommend Solution activity assesses the business value associated with the potential solutions. It compares trade-offs to identify and recommend the solution that delivers the greatest overall value.")
  expect_equal(data$templates, "OnePPM - Risk Log")
  expect_equal(data$pract, "Measure Solution Performance 1-Min Need-to-Know\r\nAnalyze Performance Measures 1-Min Need-to-Know\r\nAssess Solution Limitations 1-Min Need-to-Know\r\nAssess Enterprise Limitations 1-Min Need-to-Know\r\nRecommend Actions to Increase Solution Value")
})

test_that("get_excel_data handles arguments well", {
  data <- get_excel_data(test_path("testdata", "sample_tom_data.xlsx"), "Practices Areas", 0) %>%
    janitor::clean_names()

  expect_equal(data$practice_area, "Solution Evaluation")
  expect_equal(data$summary, "Requirements Analysis and Design Definition are the activities that BAs perform to structure and organize requirements after elicitation. This is used by BAs to define and guide change. The activities are instrumental in performing a thorough analysis and communicating with stakeholders.\r\n\r\nThe large box is referred to as the \"practice area\" and the small boxes within the practice area are referred to as \"activites\". The practice area and activities are typically conducted iteratively and can be conducted in parallel or separately. It is important to note, the prevailing standard in TS is to use the REQM process with JIRA for Requirements Management.")
  expect_equal(data$activities, "Requirements Analysis and Design Definition practice area has six activities:\r\nSpecify & Model Requirements activity analyzes, synthesizes, and refines the elicitation results into requirements and designs using analytical techniques.\r\nVerify Requirements activity ensures the requirements are designed with enough detail to be usable by a particular stakeholder. Each requirement must be consistent and high quality and the activity verifies all the requirements meet this standard.\r\nValidate Requirements activity ensures the set of requirements deliver business value and supports the goals and objectives holistically. This is an on-going process to ensure the stakeholder requirements don't conflict and if they do conflict this is exposed and resolved.\r\nDefine Requirements Architecture activity structures all the requirements so they support the overall business purpose for the change. The requirements must work effectively as a cohesive whole and achieve the desired end-state. The goal of this activity is to identify gaps.\r\nDefine Design Options activity identifies, explores and describes the different ways of meeting the needs. This activity answers the question \"What options do I have to meet the future-state?\".\r\nAnalyze Potential Value and Recommend Solution activity assesses the business value associated with the potential solutions. It compares trade-offs to identify and recommend the solution that delivers the greatest overall value.")
  expect_equal(data$templates, "OnePPM - Risk Log")
  expect_equal(data$pract, "Measure Solution Performance 1-Min Need-to-Know\r\nAnalyze Performance Measures 1-Min Need-to-Know\r\nAssess Solution Limitations 1-Min Need-to-Know\r\nAssess Enterprise Limitations 1-Min Need-to-Know\r\nRecommend Actions to Increase Solution Value")
})
whjelmar/rolemapr documentation built on Aug. 8, 2022, 1:32 p.m.