Invalid Inputs and Edge Cases Testing

1. Beyond the Happy Path: Negative Testing

So far, you've acted like a perfect user. But real users make mistakes. They might click a button before typing anything, paste in strange text, or do things you never expected. Testing for these scenarios is often called "negative testing." The goal isn't just to see if the app breaks, but to verify that it handles errors gracefully.

A simple example is a login form. The happy path is entering the correct username and password. The negative paths involve trying incorrect passwords, blank usernames, and so on.

To see this in action, let's watch a video that explains how a tester thinks about these "negative paths."

As you saw in the video, a good tester goes beyond the documentation and thinks about all the ways something could go wrong. The expected result for a negative test isn't a success screen, but rather a specific, helpful error message (like "Username is required").

2. Pushing the Limits: Understanding Edge Cases

A special type of testing involves "edge cases." These are tests that focus on the extreme boundaries or limits of your application's inputs. While negative testing deals with clearly invalid data, edge case testing probes the outer limits of what is considered valid.

For example, if a text field accepts 1 to 500 characters:

• Negative tests might include entering non-alphanumeric symbols or trying to inject code.
• Edge case tests would involve entering exactly 1 character, 500 characters, 0 characters, and 501 characters to see how the system behaves right at its boundaries.

Finding and handling edge cases is crucial for building a robust application that doesn't fail in unexpected situations.

3. Practical Exercise: Finding Your App's Weak Spots

Now it's time to apply these concepts to your own text analysis application. Let's brainstorm some negative and edge case scenarios we should test.

Brainstorming List:

1. Empty Input:

   • Test: What happens if you click "Analyze Text," "Correct Grammar," or "Summarize" when the text area is completely empty?
   • Expected Result: The application should display an error message and not attempt to send a request to the backend. In Module 8, you implemented server-side validation for this, so the backend should return an error. We want to see if the frontend displays it.

2. Whitespace Input:

   • Test: What happens if the text area contains only spaces, tabs, or new lines?
   • Expected Result: Similar to empty input, the app should ideally recognize this as invalid and show an error.

3. Very Long Input (Edge Case):

   • Test: Find a very large block of text online (e.g., a chapter from a public domain book) and paste it into the text area. Then, try using the features.
   • Expected Result: The application should remain responsive. The AI features might take longer, but the app shouldn't freeze or crash. This tests performance under load.

4. No Result to Copy:

   • Test: Without generating any results, click the "Copy to clipboard" button.
   • Expected Result: Nothing should be copied, and the application should not show an error. The button could be disabled until a result is available, but for now, we just want to ensure it doesn't break anything.

Your Task (30 minutes):

1. Update Your Test Plan:
   Open the test plan document you created in the previous lesson. Add a new section titled Negative and Edge Case Tests.

2. Create New Test Cases:
   Using the same table format, create new test cases for the four scenarios we brainstormed above. Label them TC-06, TC-07, TC-08, and TC-09. Be sure to clearly state the "Steps to Reproduce" and the "Expected Result" for each.

   • For the empty input test (TC-06), the expected result should be an error message like "Input text cannot be empty."
   • For the long input test (TC-08), the expected result might be "The app processes the request without crashing, although it may be slow."

3. Execute the Tests:

   • Start your Flask server and open the application.
   • Methodically execute each new test case.
   • Carefully document the "Actual Result" in your test plan.
   • Compare the actual result to the expected result and mark the status as "Pass" or "Fail".

Don't be discouraged if you find "Fail" cases! That's the whole point of this exercise. Every bug you find now is one your future users won't have to deal with.

Conclusion

Great work! You have now tested your application not just for its intended use, but also for unintended and extreme uses. This is a hallmark of a diligent developer and is essential for building high-quality, reliable software.

Key Takeaways:

• Negative testing is about checking how the application handles invalid data and user errors.
• Edge case testing pushes the application to its boundaries to uncover hidden flaws.
• A robust application doesn't just work on the "happy path"; it fails gracefully and predictably when things go wrong.
• Finding a "Fail" during testing is a success, as it gives you an opportunity to improve your application before anyone else sees the problem.

In our next lesson, we will focus specifically on the user's experience during these tests. We'll verify that loading indicators and error messages display correctly under all conditions, ensuring that the user always knows what's happening, whether a request is in progress or an error has occurred.