Table of Contents

1. Challenge

   Step 1: Meet the PulseCheck shift-log console

   Meet PulseCheck

   At the start of every shift, a plant-floor technician sits down at a terminal and starts typing sensor readings: temperature in degrees Fahrenheit, vibration in millimeters per second. PulseCheck's job is to look at each number the instant it arrives, decide whether the machine is Safe, drifting into a Warning zone, or already Critical, and keep doing that for every reading the technician enters until they type quit to log off. When the shift ends, PulseCheck prints one report line summarizing how many readings came in and how bad the worst one was.

   You are building that tool from the ground up, one method at a time, over the next four steps. ## What you'll build

   • Step 2 - boolean helper methods that use relational operators (<, >, <=, >=) and logical operators (&&, ||) to decide whether a single reading, or a temperature-and-vibration pair, falls inside safe bounds.
   • Step 3 - a parser that turns raw console text into a double with double.TryParse, plus braced if/else chains that classify a reading as Safe, Warning, or Critical.
   • Step 4 - a shared method that removes the threshold logic you wrote twice in Step 3, and a while loop with counter variables that keeps processing queued commands until it sees quit.
   • Step 5 - a session runner that ties every piece together, returns a value on every code path (including bad input), and builds the final report with string interpolation. ## How you'll work

   Each step hands you a starter file under src/ with the surrounding structure already in place and a // TODO: Task X.Y comment marking exactly which method body you need to finish. You'll edit only that method, then run dotnet test tests/Lab.Tests.csproj to check your work - a failing test names the behavior that's still missing, not a syntax error to hunt for. By the end of Step 5 you'll have a single console workflow that a technician could genuinely run shift after shift.

   If you get stuck, you can refer to the provided solution code for each task, available in the solution folder.

   info> This lab experience was developed by the Pluralsight team using an internally developed AI tool. All sections were verified by human experts for accuracy prior to publications. However, content may still contain errors or inaccuracies, and we recommend independent verification.
   
   To report a problem or provide feedback, click here. Feedback may be used to improve accuracy in accordance with our Privacy Policy.

2. Challenge

   Step 2: Build the foundational safe-range checks

   Relational operators define a safe band

   A reading is "safe" when it sits between a lower and an upper bound - exactly the job of relational operators. temperatureF >= 60 asks whether a value clears the floor; temperatureF <= 90 asks whether it stays under the ceiling. Neither comparison alone tells you the whole story, but together they describe a band, and PulseCheck's very first job is turning that band into a boolean your later branching logic can rely on. ## Logical operators combine two conditions into one verdict

   A machine isn't safe just because its temperature is fine - vibration has to be in range too, at the same time. That's what && is for: it only reports true when both sides are true. You already have a method that answers the temperature question; the combined check should call it rather than re-deriving the same comparison, and then && the result with a second range check for vibration.

3. Challenge

   Step 3: Parse and branch on technician input

   Turning console text into numbers

   Everything the technician types arrives as a string, but a range check needs a double. double.TryParse is built for exactly this handoff: it attempts the conversion, hands the parsed number back through an out parameter, and returns a bool telling you whether the attempt worked. Checking that bool before trusting the number is what keeps a stray typo like "72..5" from silently becoming 0 and slipping past every downstream check. ## Branching a number into a category

   With a trustworthy double in hand, the next job is sorting it into one of three labels. A braced if/else chain tests conditions top to bottom and runs the first block whose condition is true, so ordering matters: check the most severe case first, or a Critical reading might get caught by a looser Warning check before it ever reaches the branch that should have handled it. ## The same shape, a second threshold set

   Vibration needs the identical three-tier treatment - Critical, Warning, Safe - just with its own numbers and, notice, only an upper-bound Warning check instead of temperature's two-sided one. Write it now the direct way, even though the two methods will end up sharing a lot of structure; you'll deal with that duplication head-on in the next step.

4. Challenge

   Step 4: Drive the shift menu with a counting loop and a shared method

   Extracting the repeated logic

   Look back at ClassifyTemperature and ClassifyVibration: both run the same Critical/Warning/Safe if/else shape, just against different numbers. That's a signal to extract a method - write the comparison logic once, against generic parameters, and have both classifiers call it with their own thresholds. A typed parameter list like (double value, double criticalLow, double warningLow, double warningHigh, double criticalHigh) lets one method serve both callers without either one losing its own bounds. ## Looping until the technician logs off

   A real shift doesn't process one reading and stop - it keeps going until the technician types quit. A while loop paired with a counter variable is the standard shape for that: initialize an index before the loop, test it (and the current command) in the loop's condition, and increment it on every pass so the loop eventually terminates instead of running forever. ## Counting more than one thing at once

   Knowing how many readings came in isn't enough - the shift report needs to know how many were Safe versus Warning versus Critical versus unparsable. The loop shape doesn't change; you just add more counter variables and increment the right one each pass, based on what parsing and classifying that command's text produces.

5. Challenge

   Step 5: Assemble the full diagnostics session

   Ranking outcomes, not just counting them

   A shift with one Critical reading and ten Safe ones is a Critical shift, full stop - the counts alone don't say that, but a priority if/else chain does. Test the most severe count first (> 0), return immediately if it's true, and only fall through to lower-severity checks when the more serious ones are all zero. ## Building the report line

   String interpolation is what turns five separate numbers and a status string into one readable sentence. Every {expression} inside a $"..." string gets evaluated and dropped into place, so the report method's whole job is arranging parameters inside one interpolated string and returning it - no concatenation, no hardcoded numbers. ## Returning a value on every path

   The session runner is the one place all four earlier pieces meet: the tally loop, the priority check, and the report formatter. It also has to handle a shift with zero commands, which means it needs more than one return statement - an early return for the empty case, and a final return built from the other three methods' results for every other case. A method with branching logic still returns exactly once per call, but which return statement executes depends on the path taken.

6. Challenge

   Step 6: Run the application

   Every task is done, and each one was graded the moment you completed it. What you have not done yet is watch the whole application run at once -- which is the only place the pieces you wrote separately become a single working program.

   Start the application

   Open the Terminal tab and run:

   dotnet run --project src/Lab.csproj
   

   The program runs in the terminal and prints its output there. Every behaviour it shows is code you wrote in the previous steps, so read the output against what each task asked for -- that is the whole lab, working as one program. ### Run the checks yourself

   The lab ran each task's test for you as you went, but they are ordinary tests and you can run them whenever you like. The whole suite:

   dotnet test tests/Lab.Tests.csproj --nologo --verbosity quiet
   

   Or one task at a time:

   bash runTest.sh Task_2_1
   

   Each failure names the task it belongs to, so the output tells you which step to go back to rather than which line to stare at. Two things worth trying before you finish: break something on purpose and watch the matching check fail, then put it back. Knowing what a failure looks like is worth as much as knowing what a pass looks like, and it costs you nothing here.

   When you are done, everything you wrote is still in the editor tabs -- the lab is yours to keep reading.