this should be only for polkadot network

This isn't wrong but it's hacky.
We don't really need to test this - i.e. what happens on AssetHub.

What I'd suggest to do is just send an XCM sequence from ParaC to ParaA and verify it can receive relay asset from it, using ParaC as reserve.

Something like:

ParaC::execute_with( | | {
    ParachainPalletXcm::send(....);
  }
);

No need to assert anything on ParaC side, just on ParaA.

I get the suggestion, but on Impl details:
How can I send relay asset C -> A if:

• relay asset is not registered in C
• Alice has no balance of relay asset in C

This part of the code is the Arrange part of the test, and the C -> A transfer the Act.
Asserting para C sovereign account is ensuring it's using C as reserve and not going back to the relay and sitting in the relay sovereign account, so it's relevant

Right now you are constructing a message that uses local execution to execute TransferReserveAsset.
Instead, you can send send an XCM sequence from C to A that will instruct ParaA to mint some new tokens and deposit them to whoever.

You can check how the aforementioned command is handled in polkadot-sdk code:

TransferReserveAsset { mut assets, dest, xcm } => {
Config::TransactionalProcessor::process(|| {
	let origin = self.origin_ref().ok_or(XcmError::BadOrigin)?;
	// Take `assets` from the origin account (on-chain) and place into dest account.
	for asset in assets.inner() {
		Config::AssetTransactor::transfer_asset(
			asset,
			origin,
			&dest,
			&self.context,
		)?;
	}
	let reanchor_context = Config::UniversalLocation::get();
	assets
		.reanchor(&dest, &reanchor_context)
		.map_err(|()| XcmError::LocationFull)?;
	let mut message = vec![ReserveAssetDeposited(assets), ClearOrigin];
	message.extend(xcm.0.into_iter());
	self.send(dest, Xcm(message), FeeReason::TransferReserveAsset)?;
	Ok(())
})
},

Based on this, you can prepare a sequence using ReserveAssetDeposited, ClearOrigin, BuyExecution, DepositAsset and that's it. Use .send(...) to directly send an XCM message.

What you want to verify is that ParaA can accept ParaC as reserve, and that we can return funds back to it.
Everything else is redundant.

For ParaC/Relay sovereign accounts check, it's not wrong but it's redundant.
The only thing we should care about is the status on ParaA (which is Astar/Shiden).
We trust that relay chain & AssetHub handle their side correctly - not something we need to test.

Anyways, I'm not making this as a request for change, just want to emphasize that we need to test how ParaA behaves. Everything else is basically redundant.

I've tried your suggestion:

    let to_para_a_amount = 10_000_000_000_000u128;
    ParaC::execute_with(|| {
        let dest = Location::new(1, [Parachain(1)]);
        let beneficiary = Location::new(0, [alice.into()]);
        
        let assets = Assets::from(Asset {
            id: AssetId(Location::new(1, Here)),
            fun: Fungible(to_para_a_amount),
        });

        let message = Xcm(vec![
            ReserveAssetDeposited(assets.clone()),
            ClearOrigin,
            BuyExecution {
                fees: Asset {
                    id: AssetId(Location::new(1, Here)),
                    fun: Fungible(to_para_a_amount),
                },
                weight_limit: Unlimited,
            },
            DepositAsset {
                assets: Wild(AllCounted(1)),
                beneficiary,
            },
        ]);
        
        assert_ok!(ParachainPalletXcm::send(
            parachain::RuntimeOrigin::signed(ALICE),
            Box::new(dest.into()),
            Box::new(VersionedXcm::from(message)),
        ));
    });

but it's not passing the filter. I got this error:
Incomplete XCMP handling: UntrustedReserveLocation, 1000

When logging in Reserves check:

ReserveAssetFilter::contains origin: Location { parents: 1, interior: X2([Parachain(1000), AccountId32 { network: Some(Kusama), id: [250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250] }]) }, asset: Asset { id: AssetId(Location { parents: 1, interior: Here }), fun: Fungible(10000000000000) }
ReserveAssetFilter::contains result: false

DotFromAssetHub::contains origin: Location { parents: 1, interior: X2([Parachain(1000), AccountId32 { network: Some(Kusama), id: [250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250, 250] }]) }, asset: Asset { id: AssetId(Location { parents: 1, interior: Here }), fun: Fungible(10000000000000) }
DotFromAssetHub::contains result: false

But with my actual test, using TransferReserveAsset with execute from ParaC, it works at intended:

ReserveAssetFilter::contains origin: Location { parents: 1, interior: X1([Parachain(1000)]) }, asset: Asset { id: AssetId(Location { parents: 1, interior: Here }), fun: Fungible(10000000000000) }
ReserveAssetFilter: bool false, 
DotFromAssetHub::contains origin: Location { parents: 1, interior: X1([Parachain(1000)]) }, asset: Asset { id: AssetId(Location { parents: 1, interior: Here }), fun: Fungible(10000000000000) }
DotFromAssetHub: bool true, 

Try to execute the send with root as the origin.

EDIT: What I suggested should work unless the XCM message gets some additional modification in send.
According to your post, there's an additiional Account32 component in the filter, which I assume comes from the fact that somewhere DescendOrigin(account) gets inserted.

It's expected for such message to be rejected by ParaA since we cannot just trust some random account to tell us that they've reserved funds on the ParaC side. E.g. if that was the case, I'd just go to Polkadot, prepare the message as you did now, and tell Astar that I want to deposit 10000000 DOTs into my account.

Try to execute the send with root as the origin.

Worked !

So I pushed like this and removed redundant checks