If you asking whether or not you can avoid having to insert NavigationMenuItem instances into the database, then the answer is yes, though ideally you would move away from simply using static methods and start using instance methods and separation of concerns so you can start mocking classes.
The first option is to take the quick but dirty approach, though this means adding testing-specific code to your production code (and personally I wouldn't use it), something like:
public static List<NavigationMenuItem> getNavigationMenuItems(String menuName, String communityId) {
List<NavigationMenuItem> navigationMenuItems;
if (!Test.isRunningTest()) {
navigationMenuItems =
[SELECT Label,Type, Target, TargetPrefs, DefaultListViewId, Position
FROM NavigationMenuItem
WHERE NavigationLinkSet.DeveloperName = :menuName
AND Status = 'Live'
AND NavigationLinkSet.NetworkId = :communityId
ORDER BY Position];
} else {
String itemsAsJSON = '[{"Label": "Abc", "Type": "ExternalLink", "Status": "Live", "Target": "www.abc.com"}]'; // Your test data here
navigationMenuItems = JSON.deserialize(itemsAsJSON, navigationMenuItems);
}
return navigationMenuItems;
}
This uses hard-coded JSON to allow in-test creation of NavigationMenuItem instances as you need, but cannot vary what is returned for different tests (that's something you could mess around with but you will start including more and more stuff in production code just for testing purposes).
The "clean" alternative I would use is to split the querying into a separate class, using a pattern similar to those used by the fflib, the selector, and start using instance (not static) methods. This then allows you to separately mock out the selector using either the StubProvider or a specialized implementation of the selector for testing purposes (this requires the class to be virtual and to have virtual methods which the stub provider does not). This mock can use the same approach of JSON deserialization to instantiate fake versions of these items.
You do, however, need to ensure you apply some form of dependency injection pattern to allow the implementation of the selector to be varied between production execution and test execution. There are different dependency injection patterns you can use (e.g. constructor or factory method/singleton) that you'll find documented in various places around the web. There's even the fflib apex mocking framework that you could adopt which recommends certain dependency injection approaches.
This "clean" approach requires significant refactoring to your over-all code, to move from static methods to instance methods and to split the code into different "layers", but it really is worth it.
