LOCKEDIN / FORWARD-DEPLOYED ENGINEERING 101
Understand it.
Then build it.
You can be an experienced engineer and still be new to agents. Start with what each thing is and how it helps a person do useful work. Explore 58 original introductions across software, agents, cloud, security and delivery. Start here without a model key; each topic connects to deeper instruction and practice.
A place to start.
Choose a short reading route, or look up a concept below.
- 101UnderstandPlain language, visual walkthrough, vocabulary
- 102Build with guidanceOriginal lessons, examples and knowledge checks
- 103Practise and explainRunnable labs, failure cases and handover
Software behavior and evidence
What is an automated test?
An automated test is a program that exercises behavior and checks an expectation. You prepare an input, call the code and compare the actual result with the required result. A fixture is the prepared input or state. An assertion is the check written as code. A test runner selects and executes tests and reports what passed or failed.
An FDE reviewing a coding agent's change needs to understand what its test command actually established. A green report can describe one selected example, an incomplete check or the wrong expectation. Read the comparison and its scope before accepting the claim.
UNDERSTAND THE SYSTEM
What did this test actually establish?
Follow one fictional ticket through an input, function, expectation and assertion. These six views explain the real Node.js lab. A passing result has to be read with the selected cases and the comparison it made.
Read the connections in plain English
- 01Test input → Function under test
A selected test calls the function with this prepared ticket.
- 02Function under test → Assertion
The function result reaches the comparison.
- 03Expected behavior → Assertion
The assertion checks the result against the stated behavior.
- 04Assertion → Runner result
An assertion failure is reported for the selected test; the runner also reports setup failures.
Check your understanding: A coding agent reports a green run. What would you inspect before trusting its claim?
Read the exact command and selected test names, confirm the relevant bodies reached meaningful assertions, compare expectations with the requirement and associate the run with the reviewed code. Filtered or weakened tests can pass while the intended behavior is still wrong.
CONNECT IT TO WHAT YOU KNOW
Start with something familiar.
Imagine checking a spreadsheet formula with a few worked examples. You choose inputs, calculate the result and compare it with an independently agreed answer. A software test makes that comparison repeatable.
Repeating a comparison does not tell you whether the agreed answer was sensible. Tests need meaningful expectations, representative examples and a command that actually executes them.
Words worth knowing
- Fixture
- Prepared example data or supporting state, such as one fictional ticket.
- Assertion
- An executable check, such as requiring actual to equal expected.
- Test runner / suite
- The program that selects, executes and reports tests / a collection of tests.
- Regression
- Previously expected behavior that a change breaks. A regression test preserves an example of that behavior.
- Unit / integration / end-to-end
- Different scopes: a small unit of code, collaborating components or a larger user flow. These labels do not establish test quality by themselves.
Useful foundations
Open a definition and diagram here. Your lesson stays in place.
Interfaces to programsWhat are a terminal, a shell and a CLI?
QUICK REFERENCE / 101
What are a terminal, a shell and a CLI?
A terminal is the window where you type and see text. A shell interprets your commands. A command-line interface (CLI) is how a program accepts those commands. An AI coding agent can use a terminal, but the terminal itself does not reason or decide what to do.
You need to understand what will run, in which folder, and with whose authority before approving a coding agent's action.
ONE EXAMPLE / FICTIONAL CASE
Follow the connections.
A fictional ticket function should allow North billing tickets to become drafts and block foreign tickets. The function forgets to check tenant. A test supplies a South ticket, observes draft and compares it with the required blocked result. That disagreement makes the assertion fail; it gives you something specific to investigate.
UNDERSTAND THE SYSTEM
What did this test actually establish?
Follow one fictional ticket through an input, function, expectation and assertion. These six views explain the real Node.js lab. A passing result has to be read with the selected cases and the comparison it made.
See what moves and why.
Read the connections in plain English
- 01Test input → Function under test
A selected test calls the function with this prepared ticket.
- 02Function under test → Assertion
The function result reaches the comparison.
- 03Expected behavior → Assertion
The assertion checks the result against the stated behavior.
- 04Assertion → Runner result
An assertion failure is reported for the selected test; the runner also reports setup failures.
Check your understanding: A coding agent reports a green run. What would you inspect before trusting its claim?
Read the exact command and selected test names, confirm the relevant bodies reached meaningful assertions, compare expectations with the requirement and associate the run with the reviewed code. Filtered or weakened tests can pass while the intended behavior is still wrong.
Work through it, step by step.
Arrange an example
Choose an input and the expected result from the agreed behavior. Include a useful allowed case as well as a refusal, so blocking everything cannot look like a repair.
What you have now: A fixture and an independent expectation.
Act and assert
Call the function and compare what it returns with what the requirement says. A test name describes intent; only the executed assertion checks it. Missing imports can stop the run before that comparison.
What you have now: An observed value and a specific comparison, or a setup failure.
Read the report with its scope
Inspect the command, selected names and actual assertions. Filtering out the foreign case or checking only the output type can make this faulty function look green. Keep the code version and the cases not exercised beside the result.
What you have now: A test claim another engineer can reproduce and interpret.
FROM RECOGNITION TO REASONING
Explain six real test runs before asking a coding agent to fix a failure.
- 01
Predict what the supplied function does for permitted, foreign and unsupported tickets.
- 02
Run the free 35-minute Node.js 24 lab. Compare an assertion failure, filtered pass, setup error, repair, overcorrection and weaker assertion.
- 03
In separate copies, repair the function and expand the filter. Explain what each change establishes without combining the experiments.
Six predictions, the actual process output and two changed-copy reports with the selected cases named.
Compare your reasoning when you are ready
The filtered run never exercises the foreign case. The setup error reaches no assertion. The weaker check accepts the wrong behavior. The repaired function passes the three supplied examples; the always-blocked control breaks the permitted case. These are local unit checks, not a deployed-service assessment.
Keep notes in your own working copy. Moving through these cards does not record completion.
TURN THE IDEA INTO USEFUL WORK
You can now go deeper.
A test result supports the cases and comparisons that actually ran against the inspected code. A local unit-test pass does not establish model quality, authentication or deployed service behavior.
Academy lessons use your existing training access. Free guides stay open.