관리자 환경설정이 값을 저장은 하지만 실제 동작에는 닿지 않던 결함군을 정리했다. 설정 화면(min/max)·저장 검증(FormRequest)·런타임 적용(Service) 세 계층이 각자 리터럴을 들고 있어 서로 조용히 갈라지던 것이 공통 원인이다. 경계값 SSoT 도입: - config/core.php `settings_limits` 를 단일 출처로 두고, FormRequest 는 이 값으로 규칙을 만들고 화면은 설정 응답의 `_meta.limits` 로 같은 값을 받아 바인딩한다. - 게시판·이커머스도 각 모듈 config 의 limits 를 동일 구조로 노출한다. 적용되지 않던 정책을 실제로 적용: - 비밀번호 최소 길이·특수문자 필수(신규 지정 7개 경로. 로그인은 제외 — 정책을 올렸을 때 기존 회원이 자기 계정에 접근조차 못 하는 데드락을 막기 위함) - 계정 잠금 시간 0 = 무한대(전용 컬럼 분리. timestamp 상한과 NULL 규약 때문에 기존 컬럼 재사용이 불가능하다) + 관리자 수동 해제 경로 - 업로드 최대 크기·허용 확장자, 게시판 첨부 개수·댓글 깊이, 페이지 첨부 정책, 장바구니 수량·구매 한도, 마일리지 사용 한도, 주문 부가세 파생 결함: - 큐 Job(sync 드라이버)이 진행 중인 요청의 Request 바인딩을 덮어써, 뒤이어 실행되는 훅 리스너가 헤더를 잃고 조용히 건너뛰었다. Job 이 원 바인딩을 복원하도록 고치고, 전송 헤더가 필요한 리스너는 동기 실행으로 선언한다. - 확장 업데이트 실패 시 상태만 되돌리고 상태 캐시를 비우지 않아, 그 확장의 관리자 화면만 캐시 TTL(기본 하루) 동안 404 로 남았다. 실패 경로에도 무효화를 대칭으로 두고, 빈 목록 자체를 캐시하지 않는다. - 글 작성 시 첨부 파일이 Service 로 전달되지 않아 검증·권한은 통과하고 첨부만 사라졌다. - 환경설정 저장 실패 안내가 내부 설정 키를 그대로 노출했다(105개 항목에 라벨 부여). 재발 방지: - audit 룰 3종(레이아웃 경계 리터럴 / FormRequest 경계 불일치 / Service 재클램프) - 테스트 실행 범위 강제 훅(check-test-scope) - 트러블슈팅 사례 2건(큐 Job 요청 오염 / 확장 상태 캐시 고착) 공개 이슈: gnuboard/g7
151 lines
5.0 KiB
PHP
151 lines
5.0 KiB
PHP
<?php
|
|
|
|
namespace Modules\Sirsoft\Ecommerce\Tests\Feature\Upgrade;
|
|
|
|
use App\Extension\UpgradeContext;
|
|
use Illuminate\Support\Facades\DB;
|
|
use Modules\Sirsoft\Ecommerce\Database\Factories\OrderFactory;
|
|
use Modules\Sirsoft\Ecommerce\Database\Factories\OrderOptionFactory;
|
|
use Modules\Sirsoft\Ecommerce\Models\Order;
|
|
use Modules\Sirsoft\Ecommerce\Tests\ModuleTestCase;
|
|
use Modules\Sirsoft\Ecommerce\Upgrades\Upgrade_1_0_5;
|
|
|
|
/**
|
|
* 1.0.5 주문 부가세 백필 업그레이드 스텝 테스트 (#493 E5)
|
|
*
|
|
* 부가세 쓰기 지점이 부분취소 재계산 1곳뿐이라, 부분취소를 겪은 주문만 값이 정상화되고
|
|
* 나머지 주문은 영구 0 이었습니다. 백필은 그 0 을 메우되, 이미 값이 있는 주문(부분취소로
|
|
* 정상화된 주문)은 건드리지 않아야 합니다 — 정상 값을 재계산으로 덮어쓰면 회계 수치가
|
|
* 조용히 바뀝니다.
|
|
*
|
|
* @scenario actor=member, change_mode=api
|
|
*
|
|
* @effects order_vat_backfilled_for_zero_only, mixed_tax_rate_summed_per_option
|
|
*/
|
|
class OrderVatBackfillTest extends ModuleTestCase
|
|
{
|
|
/**
|
|
* 부가세/과세표준을 지정한 주문을 만듭니다.
|
|
*
|
|
* @param int $totalTaxAmount 주문 과세표준
|
|
* @param int $totalVatAmount 주문 부가세 (0 = 미기록)
|
|
* @param array<int, array{taxable: int, rate: float}> $options 옵션별 과세표준·세율
|
|
* @return int 생성된 주문 ID
|
|
*/
|
|
private function makeOrder(int $totalTaxAmount, int $totalVatAmount, array $options): int
|
|
{
|
|
$order = OrderFactory::new()->create();
|
|
|
|
DB::table('ecommerce_orders')->where('id', $order->id)->update([
|
|
'total_tax_amount' => $totalTaxAmount,
|
|
'total_vat_amount' => $totalVatAmount,
|
|
]);
|
|
|
|
foreach ($options as $spec) {
|
|
$orderOption = OrderOptionFactory::new()->forOrder($order)->create([
|
|
'parent_option_id' => null,
|
|
]);
|
|
|
|
$snapshot = $orderOption->product_snapshot;
|
|
$snapshot['tax_rate'] = $spec['rate'];
|
|
|
|
DB::table('ecommerce_order_options')->where('id', $orderOption->id)->update([
|
|
'subtotal_tax_amount' => $spec['taxable'],
|
|
'product_snapshot' => json_encode($snapshot, JSON_UNESCAPED_UNICODE),
|
|
]);
|
|
}
|
|
|
|
return $order->id;
|
|
}
|
|
|
|
/**
|
|
* 1.0.5 업그레이드 스텝을 실행합니다.
|
|
*/
|
|
private function runUpgrade(): void
|
|
{
|
|
(new Upgrade_1_0_5)->run(new UpgradeContext('1.0.4', '1.0.5', '1.0.5', 'extension-upgrade'));
|
|
}
|
|
|
|
/**
|
|
* 부가세를 반환합니다.
|
|
*
|
|
* @param int $orderId 주문 ID
|
|
* @return int 부가세
|
|
*/
|
|
private function vatOf(int $orderId): int
|
|
{
|
|
return (int) Order::find($orderId)->total_vat_amount;
|
|
}
|
|
|
|
/**
|
|
* 부가세가 0 인 주문만 스냅샷 세율로 백필되는지 테스트합니다.
|
|
*/
|
|
public function test_zero_vat_order_is_backfilled_with_snapshot_rate(): void
|
|
{
|
|
$orderId = $this->makeOrder(11000, 0, [['taxable' => 11000, 'rate' => 10.0]]);
|
|
|
|
$this->runUpgrade();
|
|
|
|
$this->assertSame(1000, $this->vatOf($orderId));
|
|
}
|
|
|
|
/**
|
|
* 이미 부가세가 기록된 주문은 백필이 건드리지 않는지 테스트합니다.
|
|
*
|
|
* 부분취소로 정상화된 주문을 재계산으로 덮어쓰면 회계 수치가 조용히 바뀐다.
|
|
*/
|
|
public function test_order_with_existing_vat_is_left_untouched(): void
|
|
{
|
|
$orderId = $this->makeOrder(11000, 777, [['taxable' => 11000, 'rate' => 10.0]]);
|
|
|
|
$this->runUpgrade();
|
|
|
|
$this->assertSame(777, $this->vatOf($orderId));
|
|
}
|
|
|
|
/**
|
|
* 과세표준이 없는 주문(전액 면세)은 0 으로 남는지 테스트합니다.
|
|
*/
|
|
public function test_tax_free_order_stays_zero(): void
|
|
{
|
|
$orderId = $this->makeOrder(0, 0, [['taxable' => 0, 'rate' => 10.0]]);
|
|
|
|
$this->runUpgrade();
|
|
|
|
$this->assertSame(0, $this->vatOf($orderId));
|
|
}
|
|
|
|
/**
|
|
* 세율이 섞인 주문은 옵션별 세율로 합산되는지 테스트합니다.
|
|
*
|
|
* 주문 전체 과세표준에 단일 세율을 적용하면 값이 어긋난다.
|
|
*/
|
|
public function test_mixed_rate_order_is_summed_per_option(): void
|
|
{
|
|
$orderId = $this->makeOrder(21500, 0, [
|
|
['taxable' => 11000, 'rate' => 10.0],
|
|
['taxable' => 10500, 'rate' => 5.0],
|
|
]);
|
|
|
|
$this->runUpgrade();
|
|
|
|
// 1000(10%) + 500(5%) = 1500. 단일 세율이었다면 1955.
|
|
$this->assertSame(1500, $this->vatOf($orderId));
|
|
}
|
|
|
|
/**
|
|
* 재실행해도 결과가 같은지 테스트합니다 (멱등).
|
|
*/
|
|
public function test_backfill_is_idempotent(): void
|
|
{
|
|
$orderId = $this->makeOrder(11000, 0, [['taxable' => 11000, 'rate' => 10.0]]);
|
|
|
|
$this->runUpgrade();
|
|
$first = $this->vatOf($orderId);
|
|
|
|
$this->runUpgrade();
|
|
|
|
$this->assertSame($first, $this->vatOf($orderId));
|
|
}
|
|
}
|