From 29ebd4a5ff5c0a0eefe802a4bcaa8ef32cc5795a Mon Sep 17 00:00:00 2001

From: Fabian Homborg <FHomborg@gmail.com>

Date: Sat, 13 Mar 2021 17:22:35 +0100

Subject: [PATCH] tests: Don't break when a file unexpectedly exists

Creating a file called "xfoo" could break the highlight tests because

we'd suddenly get a color with valid_path set to true.

So what we do is simply compare foreground/background and forced

underline, but only check for path validity if we're expecting a valid

path.

If we're not expecting a valid path, we don't fail whether it is there

or not.

This means that we can't check for a non-valid path, but we don't

currently do that anyway and we can just burn that bridge when we get

to it.

cc @siteshwar @krobelus, who both came across this

---

 src/fish_tests.cpp | 11 ++++++++++-

 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/src/fish_tests.cpp b/src/fish_tests.cpp

index 5f57f9e64..3f7777138 100644

--- a/src/fish_tests.cpp

+++ b/src/fish_tests.cpp

@@ -5386,7 +5386,16 @@ static void test_highlighting() {

             // Hackish space handling. We don't care about the colors in spaces.

             if (text.at(i) == L' ') continue;

-            if (expected_colors.at(i) != colors.at(i)) {

+            auto e = expected_colors.at(i);

+            auto c = colors.at(i);

+            // Compare the colors, but don't care about pathness

+            // unless we're asking for a valid path.

+            //

+            // That way stray files in the build directory don't break the test.

+            if (e.foreground != c.foreground

+                || e.background != c.background

+                || e.force_underline != c.force_underline

+                || (e.valid_path && !c.valid_path)) {

                 const wcstring spaces(i, L' ');

                 err(L"Wrong color in test at index %lu in text (expected %#x, actual "

                     L"%#x):\n%ls\n%ls^",

-- 

2.29.2