Should I accept the candidate that is way more junior than our expectations, just because waiting for the better candidate may take months?
Wrong question, what you should really be asking is this:
Why is my company unable to attract candidates of the requisite experience level?
and unfortunately you haven't given us enough information about what sort of languages and tech stacks your company uses, in order for us to definitively answer. If, for example, your company is working for a government department that requires security clearances, or specialises in a niche language like Cobol, then you are always going to have trouble finding people.
Assuming that's not the case, then it's likely that forcing prospective hires to take a test before even being interviewed is discouraging them from applying. Right now, developers - especially good ones - get to pick and choose where they work, which means that given the choice between a job prospect that requires them to write a test versus one that doesn't, they're probably going to go for the latter.
This is not to say that a test is a bad thing: it allows you to weed out the chancers who are completely incompetent, which means your company doesn't have to waste time on interviews that will go nowhere. But you should remember that for a developer to come to your office and write a test, is an investment of time from their side.
My suggestion would be to ditch the test. Go directly to interviews and instead of looking for candidates that are experienced in the tech stack your company uses, and/or can answer rote questions about said stack - concentrate on finding candidates who are able and willing to learn. Personally, I'd be more interested in a candidate with many years of experience spread out over a wide variety of languages, versus someone who has spent their entire career ensconced in the comfortable bubble of the one thing they know.
Once you find someone who you think is going to fit, don't sign them onto full employment. Instead, offer them a 3-month contract that is essentially a probationary period; at the end of the period, you either convert that contract to full employment if the candidate has performed well; or if they have not performed as needed, the contract simply lapses and they need to make alternative arrangements.
You are probably also using the current test as a way to ensure that anyone hired will write quality code, but this is not a reliable indicator: just as people can lie about their experience and skillset, so they can write code that is far better than their norm. Quality is ensured via regular code reviews, not a once-off test.
Finally, you should consider that a test (which is probably timed and taken in an unfamiliar environment, hence somewhat nerve-wracking which will impact performance) is not necessarily the best tool to judge someone's competency. In particular, a written test is an extremely poor tool because no programmer writes code out by hand on paper: we live in IDEs and command-lines with productivity features that we take for granted and probably can't live without.
Anecdote: I work for a software company that also uses a test as a pre-screening. Not only are we in the same boat as you regarding getting enough developers, one of my friends wrote our test and flunked it, which to me was absurd because I know his skills... after being rejected by my company, he's gone on to become the head architect of a different company.