For people here that may ask themselves just how exactly one could test regular expressions, I recommend a visual tool like [0]. Having the regex structure and meaning drawn in front of you helps tremendously.

That, and for the love of God please comment any non-trivial regexp. Either like this, with 'x' option:

  preg_match('/^
              .*              # Match any number of characters...
              (?=.{6,})       # ... AND match at least 6 characters (lookahead) ...
              (?=.*\d)        # ... AND match one digit after any number of characters (lookahead) ...
              (?=.*[a-zA-Z])  # ... AND match one letter after any number of characters (lookahead) ...
              .*              # ... AND allow any number of characters later.
              $/x', $password);

... or just with normal programming language comments and stitching regexp from multiple strings in multiple lines. Also give some semantic meaning to groups if you use them, e.g. tag them with constants so that your code isn't full of stuff "result.get(3)", which makes you waste time on trying to recall what was that group 3 in the code from last month.

I know it's pretty much software engineering 101. It's the basics of basics. But from my experience, even the brightest of engineers in most serious projects suddenly forget how to write code when they touch regular expressions.

[0] - https://www.debuggex.com

Using tools is good, but also people should test them in their unit test, for what it should/should not be accepted

If you're forbidding items beginning with numbers, just have a test try passing '1a' and failing the match

I agree of course. Unit tests like that are both basic sanity checks and, more importantly, protect you from stupid mistakes when the regexp has to be changed.