Thread by @isocroft

@kulboi4real If you have to think of test cases for TDD. I am sorry but either one of two things are wrong.

1) The top-level functional requirements aren’t properly done and/or understood by the team or software engineer working on it

2) You don’t know how to translate requirements to tests

@kulboi4real Translating takes understanding of what’s important to the success of that functionality.

For instance How would you test a React component OR a web route on the backend in the context of the business rules that make it function ?

There’s a simple trick to this and I’ll share

@kulboi4real Now, even though test design is a manual process, it is still a logical one too. Same for Unit/Integration tests.

Don’t focus on behavior and properties of the single software artifact/unit you’ve just built. Focus on the output under given conditions that match the requirements

@kulboi4real Let me break it down a bit more:

For each top-level functional requirement, you are focused on the output under given condition(s). Which is why we use the term “Assertion”.

Assertions are the result of combining condition(s) with output. They are the lifeblood of tests

@kulboi4real Tests (Test cases) have a basic structure

Condition(s)
^
|
|
Input——> (Software artifact) ——> Output

@kulboi4real The reason I put up the figure above (diagram of a Test case) ☝🏾 (check the tweet preceding this one) is because that is the pattern you need to fit a React component OR web route action class method or any software unit into. E.g A react component recieves input and gives output

@kulboi4real The output is supposed to change (or remain the same) under given conditions. Remember, I said focus on output and conditions (a condition could be the data type of the input or passing no input at all to software artifact/unit)

Let me give a real-life example:

@kulboi4real @threadreaderapp unroll