Apparently, it is considered bad practice to leave out the refactor step in red-green-refactor. I made this mistake recently in one of my projects.
That being said, I've always learned in my lectures in testing that you have to make the tests pass with as simple code as possible (no layers, no architecture) and then refactor afterwards so that the other tests work. Moreover, if your tests can pass with spaghetti code, that means you need to write more tests (I'm not sure if this is always true).
A few questions:
1) If none of my tests enforce non-spaghetti code, does that make it ok to make them pass with spaghetti code (for example, with hardcoded values)?
2) Is it bad practice to make all my tests pass with spaghetticode? I've managed to do this for all my unit tests and integration tests.
A tester told me this is the worst mentality one could have testing wise.
Unclean code is the work of the devil; ok, that may be a bit much but it certainly leads to a lot of pain and suffering. You should make every effort to clean up your code once you get a new test to pass. Doing anything less than that is not the mark of a professional developer.
There's something to say for "if your tests can pass with spaghetti code, that means you need to write more tests". Your methods are probably taking on too much responsibility, and you should either break them up, or split your class in tinier more cohesive parts. Methods should perform a simple well-defined task, and you should be able to write several tests to test the various possible paths through one such method.