This can be final and set it to ValidationType.missing on the else

nit: you can iterate directly over the systemInfoElements (as well as the lineElements) and avoid using .elementAt

for (final String curLine in systemInfoElements) {...}

nice, i meant to actually refactor this to use that notation

Does adding the question mark not make this also match 'BIOS Version: ?

I don't believe so, the question mark should be only looking for 0 or 1 newline characters before OS. Unless I had the wrong assumption there?

I added the question mark incase there was no new line character before the OS Version line on print out

So in "BIOS Version:" won't there be 0 newline characters before "OS"?

whether i'm right or wrong, this should be test cases in the unit tests :)

I see what you mean now, I'm going to try a refactor with multiLine enabled so that I can specify the start of the line as a reference point

I'll build some test cases with multiline enabled when i get back. thanks for the review! 😁

I don't really think this helper method is carrying its weight. First, I would move the regex string to a top level and document there what it is intended to match. Then you can replace it with regex.allMaches(contents)

Oh, I think from reading @christopherfujino's comment, the idea was to embed the version matching pattern in this method to make it easy to test.

From reading the test cases, I think it would work OK without this as a public method. But if you're not going to specifically test it you should drop this.

Yeah, Chris mentioned that it would be helpful to make this regex helper a method that we can unit test independently, so that we can feed it test strings as we start to encounter newer versions of the stdout from systeminfo.

You're basically not testing this method, though, because this method itself is trivial. I would just test the regex itself

I was thinking that this helper method would also include lines 58-61 and return a boolean. Also the rather than passing the pattern (which is actually what you want to test), that the function would receive resultStdout.

Then your test can look (something) like:

test('validateVersionString() correctly validates the output of `systeminfo`', () {
  bool result = validateVersionString('123');
  expect(result, isFalse);
  result = validateVersionString('OS Version:   8.0.0');
  // Too old
  expect(result, isFalse);
  result = validateVersionString('OS Version:     11.1.2');
  expect(result, isTrue);
});

I think this approach is fine too, its the middle ground that isn't very useful

I do agree with @jonahwilliams that the static method was very trivial but @christopherfujino what your test looks like is essentially what the entire validator was built to check.

I shied away from creating a regex method that returned a boolean because I didn't want to assume that there would only be one match within the stdout. The conditionals beginning on line 60 were added to ensure that the matches only returned 1 result AND that the major version was valid.

ok, makes sense, i'm fine with you removing this function