You test components in isolation, you test integration of components, you run simulations of the entire rocket, and finally you test the rocket launch.
You’ll catch issues along the way, but you can’t catch all of them before a full launch test. That’s why there are launch tests.
This can get as far as the test plan is complete, multiply iterated under different interface conditions and thorough. And you are still relying upon the adherence of the simulated models to the physical reality.
Real tests do all of this at once with no option to escape reality.
Again, one thing is automating thorough software tests, another one is testing physical stuff.
That might still happen this year, it’s the next step in the development plan.
What makes these launches “non-production” tests is that they are not carrying any valuable payload. Blowing up rockets like this is exactly what gives the company it’s advantage over competitors who try to anticipate everything during design stages.
Testing their ability to deploy satellites is a short-term goal that will make them money now. Testing refuelling will be needed for Luna and Mars missions, but that’s a long way off anyway.
You test components in isolation, you test integration of components, you run simulations of the entire rocket, and finally you test the rocket launch.
You’ll catch issues along the way, but you can’t catch all of them before a full launch test. That’s why there are launch tests.
This can get as far as the test plan is complete, multiply iterated under different interface conditions and thorough. And you are still relying upon the adherence of the simulated models to the physical reality.
Real tests do all of this at once with no option to escape reality.
Again, one thing is automating thorough software tests, another one is testing physical stuff.
This is the programmer fallacy if you have a bunch of code passing unit tests, it’s going to work when combined.
Thats not what he said. Unit tests are the first stage, and are very useful at isolating the problem.
Integration tests are the next where multiple units are combined.
Then there is staging.
Did they say that?
1 reply →
Test code by running it.
Test a rocket by launching it.
I would consider these launches test launches. Production is when they include commercial payloads and humans.
In production? I don't disagree that tests 'in production' are sometimes necessary (canary tests), but most of the quirks are often fixed by then.
Honestly I thought they would be live testing fuel exchange in orbit by now. Seems pretty far from it sadly.
That might still happen this year, it’s the next step in the development plan.
What makes these launches “non-production” tests is that they are not carrying any valuable payload. Blowing up rockets like this is exactly what gives the company it’s advantage over competitors who try to anticipate everything during design stages.
There was no real payload on this, so I'd argue it's closer to a QA environment than production.
It's true that other rocket companies are treating launches as production, but SpaceX has always been doing "hardware-rich" testing.
Some domains have so many different parties doing different things, you just have to test in production. Rockets are probably one of them.
Testing their ability to deploy satellites is a short-term goal that will make them money now. Testing refuelling will be needed for Luna and Mars missions, but that’s a long way off anyway.
They had that on the timeline for 2023, so it's reasonable to assume they would do it.
launching a rocket is far more analogulous to shipping a release, than it is running code.
Launching a rocket is far more complex than shipping a release.
It is more like an "all or nothing" process.