Be professional. State your concerns to your manager, and probably a level up as well. Make it clear that you don't have any confidence in the project as planned and you think that the cause is a hopeless one.
Then (assuming you want to keep working there, as the author seems to) make it clear that if they still want to go ahead then you are fully committed to helping them to the best of your abilities.
But a project in as bad a state as described?
Get another job.
The downside to such a strategy might be that the reason for the impending failure is the manager, and/or the level up as well.
Most organizations operate (and should operate) according to what the top-level decides should happen. If the top-level defaults on that responsibility, then chaos will ensue.
In those cases a value judgment of the process is a value judgment of the organization, and most astute managers realize it sometimes before the "innocent" (i.e., socially naive on organizational dynamics) system builder guy realizes it.
Well yeah, the reason I mentioned the level up is that sometimes your manager is the problem, and sometimes your manager isn't telling the business about the problem.
If both of those are part of the problem (don't worry! All is well!), rather than realistic (we know there are serious problems here but we think there's a chance/we'd like to try anyway), then it's time to think about the systemic problems and consider finding yourself a new job (IMHO).
+1. Communication and professionalism are your best bet, here. It's amazing how often engineers think the managers know all these things, as if they've mentioned it a million times, but no one is listening.
Sometimes the problem is that the issues are communicated, but not the severity. So, you might raise that the database is too complex with 100+ tables, but if the manager does not have an intuitive sense for the consequences of that problem, it might not register as a project-destroying issue. That becomes the disconnect later, and when things go pear-shaped, these disconnects become issues of contention.
The worst thing you can do is to raise these issues quietly and just keep trucking, as if you've done your job, and that's that. [wiping hands gesture] If management doesn't realize that the project is headed for disaster, that's on you (and the others on the team).
But, if you're able to convey the severity of these issues clearly and professionally, the conversation might turn to what can get done in the near term that would be valuable. Or, to the point of other commenters, there might be other factors at play, and the manager might want you to keep trucking anyway. In this case, provided you have been clear about the risks and threats, you really have done your job.
As a parting thought, you could also raise an issue around "what type of company" you want to work for. Perhaps if they need to rock out a rough proof of concept with no automated testing (or any testing!), that's one thing, but I wouldn't want to work at a company that doesn't take testing seriously. So perhaps if this is a manic sprint to prove something, we can all get on board with cowboy coding, but once the dust settles, it will take x amount of time to shore up the work with xyz types of tests. If they aren't on board with taking their medicine and putting the right tests in place, then that might be reason to depart even if the proof of concept succeeds.
Then (assuming you want to keep working there, as the author seems to) make it clear that if they still want to go ahead then you are fully committed to helping them to the best of your abilities.
But a project in as bad a state as described? Get another job.