rubyn-code 0.1.0

data/skills/rspec/mocking_stubbing.md

@@ -0,0 +1,209 @@
+# RSpec: Mocking and Stubbing
+
+## Pattern
+
+Use `instance_double` for type-safe mocks. Stub external dependencies, not the object under test. Prefer dependency injection over global stubs. Use `allow` for setup, `expect` for assertions.
+
+```ruby
+# GOOD: instance_double verifies the interface exists
+RSpec.describe Orders::CreateService do
+  let(:user) { build_stubbed(:user) }
+  let(:mailer) { instance_double(OrderMailer) }
+  let(:message) { instance_double(ActionMailer::MessageDelivery) }
+
+  before do
+    allow(OrderMailer).to receive(:confirmation).and_return(message)
+    allow(message).to receive(:deliver_later)
+  end
+
+  it "sends a confirmation email" do
+    expect(OrderMailer).to receive(:confirmation).with(an_instance_of(Order))
+    described_class.call(valid_params, user)
+  end
+end
+```
+
+```ruby
+# GOOD: Stub external HTTP dependency
+RSpec.describe Embeddings::EmbeddingClient do
+  let(:client) { described_class.new(base_url: "http://localhost:8000") }
+
+  before do
+    stub_request(:post, "http://localhost:8000/embed")
+      .with(body: hash_including("texts"))
+      .to_return(
+        status: 200,
+        body: { embeddings: [[0.1, 0.2, 0.3]], dimensions: 1024, count: 1 }.to_json,
+        headers: { "Content-Type" => "application/json" }
+      )
+  end
+
+  it "returns embeddings from the service" do
+    result = client.embed(["def hello; end"])
+    expect(result.first.length).to eq(3)
+  end
+end
+```
+
+```ruby
+# GOOD: Dependency injection makes stubbing natural
+class Orders::CreateService
+  def initialize(mailer: OrderMailer, notifier: WarehouseNotifier)
+    @mailer = mailer
+    @notifier = notifier
+  end
+
+  def call(params, user)
+    order = user.orders.create!(params)
+    @mailer.confirmation(order).deliver_later
+    @notifier.notify(order)
+    order
+  end
+end
+
+# Test: inject doubles instead of patching globals
+RSpec.describe Orders::CreateService do
+  let(:mailer) { instance_double(OrderMailer) }
+  let(:notifier) { instance_double(WarehouseNotifier) }
+  let(:service) { described_class.new(mailer: mailer, notifier: notifier) }
+
+  before do
+    allow(mailer).to receive_message_chain(:confirmation, :deliver_later)
+    allow(notifier).to receive(:notify)
+  end
+
+  it "notifies the warehouse" do
+    expect(notifier).to receive(:notify).with(an_instance_of(Order))
+    service.call(valid_params, user)
+  end
+end
+```
+
+`allow` vs `expect`:
+
+```ruby
+# allow: Setup — "if this gets called, return this"
+# No failure if it's never called
+allow(service).to receive(:call).and_return(result)
+
+# expect: Assertion — "this MUST be called"
+# Fails if it's never called
+expect(service).to receive(:call).with(expected_args)
+```
+
+## Why This Is Good
+
+- **`instance_double` catches interface drift.** If you rename `OrderMailer#confirmation` to `OrderMailer#order_confirmation`, tests using `instance_double(OrderMailer)` that stub `:confirmation` immediately fail. A plain `double` wouldn't catch this — the test would pass while production breaks.
+- **Stubbing externals isolates the unit.** The service test doesn't depend on a running email server, a warehouse API, or an embedding service. It tests the orchestration logic in isolation.
+- **Dependency injection is better than global patching.** `allow(OrderMailer).to receive(...)` patches a global constant. Injecting a double via the constructor is explicit, doesn't affect other tests, and doesn't depend on load order.
+- **`allow` for setup, `expect` for assertions** keeps intent clear. Setup stubs say "the world looks like this." Assertion mocks say "this thing must happen."
+- **WebMock for HTTP.** `stub_request` prevents real HTTP calls in tests, returns controlled responses, and verifies the request was made correctly.
+
+## Anti-Pattern
+
+Mocking the object under test, overuse of `any_instance`, and testing implementation details:
+
+```ruby
+# BAD: Stubbing the object under test
+RSpec.describe Order do
+  it "calculates total" do
+    order = build(:order)
+    allow(order).to receive(:line_items).and_return([
+      double(total: 10), double(total: 20)
+    ])
+    expect(order.calculate_total).to eq(30)
+  end
+end
+
+# BAD: any_instance_of — fragile, global, affects all instances
+RSpec.describe OrdersController do
+  it "creates an order" do
+    allow_any_instance_of(Order).to receive(:save).and_return(true)
+    post :create, params: { order: valid_params }
+    expect(response).to redirect_to(orders_path)
+  end
+end
+
+# BAD: Testing method call sequence — implementation detail
+RSpec.describe Orders::CreateService do
+  it "creates then sends then notifies" do
+    expect(Order).to receive(:create!).ordered
+    expect(OrderMailer).to receive(:confirmation).ordered
+    expect(WarehouseNotifier).to receive(:notify).ordered
+    described_class.call(params, user)
+  end
+end
+
+# BAD: Plain doubles with no type checking
+let(:user) { double("User", name: "Alice", save: true, banana: "yellow") }
+# "banana" isn't a User method — double won't catch this
+```
+
+## Why This Is Bad
+
+- **Stubbing the object under test.** If you stub `order.line_items`, you're not testing `calculate_total` against real data — you're testing that it sums a stubbed array. The real method might have a bug in how it queries line items, and you'll never know.
+- **`any_instance_of` is global.** It affects every instance of the class in the entire test, including instances created inside the code under test. It's unpredictable, hard to scope, and a sign of untestable design.
+- **Testing call order is brittle.** If someone reorders the operations (notify before mail, or in parallel), the test breaks even though the behavior is correct. Test outcomes, not sequence.
+- **Plain doubles don't verify interfaces.** `double("User", banana: "yellow")` creates a fake that responds to `:banana`. If `User` doesn't have a `banana` method, you'll never know until production. `instance_double(User)` would catch this immediately.
+
+## When To Apply
+
+- **Stub external services.** HTTP APIs, email delivery, file storage, third-party SDKs — anything outside your application boundary. Use WebMock for HTTP, instance_double for Ruby dependencies.
+- **Stub slow operations in unit tests.** Database queries in a service spec that's testing logic, not persistence. But prefer `build_stubbed` over mocking AR.
+- **Use `expect(...).to receive` when verifying side effects.** "Did the mailer get called?" is a legitimate assertion. "Did the service call `create!` then `deliver_later` in that order?" is not.
+- **Inject dependencies** when a class collaborates with external services. Constructor injection (`def initialize(mailer:)`) makes testing trivial.
+
+## When NOT To Apply
+
+- **Don't mock what you can build.** `build_stubbed(:user)` is better than `instance_double(User)` when you need a realistic user object. Doubles are for collaborators you want to isolate from, not for the subject's own data.
+- **Don't mock ActiveRecord queries in model specs.** If you're testing a scope, run the real query against the test database. Mocking `where` defeats the purpose.
+- **Don't use mocks in integration/system tests.** These tests exist to verify the full stack. Mocking within them undermines their value.
+- **Don't mock more than 2-3 dependencies.** If a test needs 5 mocks to set up, the class under test has too many dependencies. Refactor the class before adding more mocks.
+
+## Edge Cases
+
+**`class_double` for class method stubbing:**
+
+```ruby
+auth_service = class_double(AuthService, verify: true)
+stub_const("AuthService", auth_service)
+expect(auth_service).to receive(:verify).with("token").and_return(user)
+```
+
+**`receive_message_chain` — use sparingly:**
+
+```ruby
+# Acceptable for mailer chains
+allow(OrderMailer).to receive_message_chain(:confirmation, :deliver_later)
+
+# NOT acceptable for business logic chains — sign of Law of Demeter violation
+allow(order).to receive_message_chain(:user, :company, :billing_address, :country)
+# Fix the code: order.billing_country instead of 4-deep chain
+```
+
+**Verifying arguments:**
+
+```ruby
+expect(mailer).to receive(:confirmation).with(
+  having_attributes(id: order.id, total: 100)
+)
+
+expect(client).to receive(:post).with(
+  "/api/v1/orders",
+  hash_including(status: "pending")
+)
+```
+
+**Spy pattern (assert after the fact):**
+
+```ruby
+notifier = instance_double(WarehouseNotifier)
+allow(notifier).to receive(:notify)
+
+service = described_class.new(notifier: notifier)
+service.call(params, user)
+
+expect(notifier).to have_received(:notify).with(an_instance_of(Order))
+```
+
+This is useful when you want `allow` in setup and assertion at the end, rather than `expect` before the action.

data/skills/rspec/request_specs.md

@@ -0,0 +1,212 @@
+# RSpec: Request Specs
+
+## Pattern
+
+Test controllers through request specs, not controller specs. Request specs exercise the full middleware stack — routing, params parsing, authentication, the action, and the response — giving you confidence the endpoint works end to end.
+
+```ruby
+# spec/requests/orders_spec.rb
+RSpec.describe "Orders", type: :request do
+  let(:user) { create(:user) }
+
+  before { sign_in user }
+
+  describe "GET /orders" do
+    it "returns the user's orders" do
+      create_list(:order, 3, user: user)
+      create(:order) # belongs to another user
+
+      get orders_path
+
+      expect(response).to have_http_status(:ok)
+      expect(response.body).to include("3 orders")
+    end
+  end
+
+  describe "POST /orders" do
+    let(:product) { create(:product, stock: 10) }
+    let(:valid_params) do
+      {
+        order: {
+          shipping_address: "123 Main St",
+          line_items_attributes: [{ product_id: product.id, quantity: 2 }]
+        }
+      }
+    end
+
+    context "with valid params" do
+      it "creates an order" do
+        expect {
+          post orders_path, params: valid_params
+        }.to change(Order, :count).by(1)
+      end
+
+      it "redirects to the order" do
+        post orders_path, params: valid_params
+        expect(response).to redirect_to(Order.last)
+      end
+    end
+
+    context "with invalid params" do
+      it "returns unprocessable entity" do
+        post orders_path, params: { order: { shipping_address: "" } }
+        expect(response).to have_http_status(:unprocessable_entity)
+      end
+
+      it "does not create an order" do
+        expect {
+          post orders_path, params: { order: { shipping_address: "" } }
+        }.not_to change(Order, :count)
+      end
+    end
+  end
+
+  describe "GET /orders/:id" do
+    it "returns the order" do
+      order = create(:order, user: user)
+      get order_path(order)
+      expect(response).to have_http_status(:ok)
+    end
+
+    it "returns not found for another user's order" do
+      other_order = create(:order)
+      expect {
+        get order_path(other_order)
+      }.to raise_error(ActiveRecord::RecordNotFound)
+    end
+  end
+
+  describe "DELETE /orders/:id" do
+    it "destroys the order" do
+      order = create(:order, user: user)
+      expect {
+        delete order_path(order)
+      }.to change(Order, :count).by(-1)
+    end
+
+    it "redirects to the index" do
+      order = create(:order, user: user)
+      delete order_path(order)
+      expect(response).to redirect_to(orders_path)
+    end
+  end
+end
+```
+
+For JSON APIs:
+
+```ruby
+RSpec.describe "API::V1::Orders", type: :request do
+  let(:user) { create(:user) }
+  let(:headers) { { "Authorization" => "Bearer #{user.api_token}" } }
+
+  describe "GET /api/v1/orders" do
+    it "returns orders as JSON" do
+      create_list(:order, 2, user: user)
+
+      get "/api/v1/orders", headers: headers
+
+      expect(response).to have_http_status(:ok)
+      json = JSON.parse(response.body)
+      expect(json["orders"].length).to eq(2)
+    end
+  end
+
+  describe "POST /api/v1/orders" do
+    it "creates and returns the order" do
+      post "/api/v1/orders", params: valid_params.to_json,
+                             headers: headers.merge("Content-Type" => "application/json")
+
+      expect(response).to have_http_status(:created)
+      json = JSON.parse(response.body)
+      expect(json["order"]["id"]).to be_present
+    end
+  end
+end
+```
+
+## Why This Is Good
+
+- **Tests what the user experiences.** A request spec hits the same code path as a real browser or API client. Routing, middleware, authentication, params parsing, the action, and the response are all exercised.
+- **Catches integration bugs.** A controller spec might pass with the correct params, but a request spec catches a broken route, a missing authentication check, or a middleware that strips a header.
+- **Rails official recommendation.** Since Rails 5, the Rails team recommends request specs over controller specs. Controller specs are considered legacy.
+- **Simpler setup.** No `assigns` or `controller` objects to reason about. Just HTTP verbs, paths, params, and response assertions.
+
+## Anti-Pattern
+
+Using controller specs with `assigns` and internal assertions:
+
+```ruby
+# LEGACY — do not write new tests this way
+RSpec.describe OrdersController, type: :controller do
+  describe "GET #index" do
+    it "assigns @orders" do
+      order = create(:order)
+      get :index
+      expect(assigns(:orders)).to include(order)
+    end
+
+    it "renders the index template" do
+      get :index
+      expect(response).to render_template(:index)
+    end
+  end
+
+  describe "POST #create" do
+    it "assigns a new order" do
+      post :create, params: { order: valid_attributes }
+      expect(assigns(:order)).to be_a(Order)
+      expect(assigns(:order)).to be_persisted
+    end
+  end
+end
+```
+
+## Why This Is Bad
+
+- **Tests implementation, not behavior.** `assigns(:orders)` tests that the controller set an instance variable — an implementation detail. The user doesn't care about instance variables; they care about what the page contains.
+- **Skips the middleware stack.** Controller specs bypass routing, Rack middleware, and Devise authentication. A test can pass even if the route is broken or auth is misconfigured.
+- **`assigns` is deprecated.** Rails removed `assigns` from the default stack. You need the `rails-controller-testing` gem to use it, which is a sign you're going against the grain.
+- **Brittle.** If you rename an instance variable from `@orders` to `@user_orders`, every controller spec breaks even though the behavior is unchanged.
+
+## When To Apply
+
+- **Every controller endpoint gets a request spec.** This is not optional. If there's a route, there's a request spec.
+- **Test the happy path and the primary failure path for each action.** Create → success + validation failure. Update → success + validation failure. Show → found + not found. Index → with data + empty.
+- **Test authentication and authorization.** Unauthenticated access returns 401. Accessing another user's resource returns 404 (scoped query) or 403 (authorization check).
+
+## When NOT To Apply
+
+- **Don't test framework behavior.** Don't test that `before_action :authenticate_user!` calls Devise. Test that an unauthenticated request returns 401. The mechanism doesn't matter — the outcome does.
+- **Don't test rendering details in request specs.** Use view specs or system specs for "the page shows the order total." Request specs check status codes, redirects, and JSON structure.
+- **Don't test service object logic in request specs.** If `Orders::CreateService` has complex business logic, test it in a service spec. The request spec just verifies the controller delegates correctly and handles the result.
+
+## Edge Cases
+
+**Testing file uploads:**
+Use `fixture_file_upload`:
+
+```ruby
+it "accepts an attachment" do
+  file = fixture_file_upload("receipt.pdf", "application/pdf")
+  post orders_path, params: { order: { receipt: file, **valid_params } }
+  expect(response).to redirect_to(Order.last)
+end
+```
+
+**Testing streaming responses:**
+Request specs receive the full response after streaming completes. If you need to test the streaming behavior itself, use a system spec with Capybara.
+
+**Shared authentication setup:**
+Use a shared context to DRY up auth:
+
+```ruby
+RSpec.shared_context "authenticated user" do
+  let(:user) { create(:user) }
+  before { sign_in user }
+end
+
+RSpec.describe "Orders", type: :request do
+  include_context "authenticated user"
+end
+```

data/skills/rspec/service_specs.md

@@ -0,0 +1,262 @@
+# RSpec: Testing Service Objects
+
+## Pattern
+
+Test service objects in isolation. Pass in dependencies as doubles. Assert on the result object, not on implementation details. Test the happy path, each failure mode, and edge cases.
+
+```ruby
+# spec/services/orders/create_service_spec.rb
+RSpec.describe Orders::CreateService do
+  let(:user) { create(:user) }
+  let(:valid_params) do
+    {
+      shipping_address: "123 Main St",
+      line_items_attributes: [
+        { product_id: product.id, quantity: 2 }
+      ]
+    }
+  end
+  let(:product) { create(:product, stock: 10, price: 25.00) }
+
+  describe ".call" do
+    context "with valid params and sufficient stock" do
+      it "returns a successful result" do
+        result = described_class.call(valid_params, user)
+        expect(result).to be_success
+      end
+
+      it "creates an order" do
+        expect { described_class.call(valid_params, user) }
+          .to change(Order, :count).by(1)
+      end
+
+      it "creates the order for the correct user" do
+        result = described_class.call(valid_params, user)
+        expect(result.order.user).to eq(user)
+      end
+
+      it "sends a confirmation email" do
+        expect { described_class.call(valid_params, user) }
+          .to have_enqueued_job(ActionMailer::MailDeliveryJob)
+      end
+    end
+
+    context "with insufficient stock" do
+      let(:product) { create(:product, stock: 0, price: 25.00) }
+
+      it "returns a failed result" do
+        result = described_class.call(valid_params, user)
+        expect(result).not_to be_success
+      end
+
+      it "includes an error message" do
+        result = described_class.call(valid_params, user)
+        expect(result.order.errors[:base]).to include("Insufficient inventory")
+      end
+
+      it "does not create an order" do
+        expect { described_class.call(valid_params, user) }
+          .not_to change(Order, :count)
+      end
+
+      it "does not send a confirmation email" do
+        expect { described_class.call(valid_params, user) }
+          .not_to have_enqueued_job(ActionMailer::MailDeliveryJob)
+      end
+    end
+
+    context "with invalid params" do
+      let(:invalid_params) { { shipping_address: "" } }
+
+      it "returns a failed result" do
+        result = described_class.call(invalid_params, user)
+        expect(result).not_to be_success
+      end
+
+      it "returns validation errors on the order" do
+        result = described_class.call(invalid_params, user)
+        expect(result.order.errors).to be_present
+      end
+    end
+  end
+end
+```
+
+Testing service objects that call external services — inject doubles:
+
+```ruby
+# spec/services/embeddings/codebase_indexer_spec.rb
+RSpec.describe Embeddings::CodebaseIndexer do
+  let(:project) { create(:project) }
+  let(:embedding_client) { instance_double(Embeddings::EmbeddingClient) }
+  let(:fake_embeddings) { [Array.new(1024) { rand(-1.0..1.0) }] }
+
+  subject(:indexer) { described_class.new(embedding_client: embedding_client) }
+
+  before do
+    allow(embedding_client).to receive(:embed).and_return(fake_embeddings)
+  end
+
+  describe "#index_file" do
+    let(:file_content) do
+      <<~RUBY
+        class Order < ApplicationRecord
+          belongs_to :user
+          has_many :line_items
+
+          def total
+            line_items.sum(&:subtotal)
+          end
+        end
+      RUBY
+    end
+
+    it "chunks the file into classes and methods" do
+      indexer.index_file(project, "app/models/order.rb", file_content)
+      chunks = project.code_embeddings
+
+      expect(chunks.pluck(:chunk_type)).to include("class", "method")
+    end
+
+    it "calls the embedding client with chunk content" do
+      expect(embedding_client).to receive(:embed).with(array_including(/class Order/))
+      indexer.index_file(project, "app/models/order.rb", file_content)
+    end
+
+    it "stores embeddings on the project" do
+      expect { indexer.index_file(project, "app/models/order.rb", file_content) }
+        .to change(project.code_embeddings, :count).by_at_least(1)
+    end
+
+    it "records the file hash for change detection" do
+      indexer.index_file(project, "app/models/order.rb", file_content)
+      embedding = project.code_embeddings.last
+
+      expect(embedding.file_hash).to eq(Digest::SHA256.hexdigest(file_content))
+    end
+  end
+end
+```
+
+## Why This Is Good
+
+- **Tests behavior, not implementation.** The test asserts `result.success?` and `result.order.user == user` — observable outcomes. It doesn't assert which internal methods were called or in what order.
+- **Each context tests one scenario.** Happy path, insufficient stock, invalid params — each is a separate context with its own setup and assertions. A failure tells you exactly which scenario broke.
+- **Injected dependencies are doubled.** `EmbeddingClient` is an `instance_double` — the test doesn't need a running Python service. It verifies the indexer calls the client correctly and processes the result.
+- **`described_class.call`** uses the same interface as production code. The test is a client of the service, exercising it the way real code would.
+- **Side effects are tested explicitly.** "sends a confirmation email" and "does not send a confirmation email" are separate assertions. The happy path verifies the side effect happens; the failure path verifies it doesn't.
+
+## Anti-Pattern
+
+Testing internal method calls, mocking the service itself, and mixing unit and integration concerns:
+
+```ruby
+# BAD: Testing implementation sequence
+RSpec.describe Orders::CreateService do
+  it "calls methods in order" do
+    service = described_class.new(params, user)
+    expect(service).to receive(:validate_inventory).ordered
+    expect(service).to receive(:create_order).ordered
+    expect(service).to receive(:charge_payment).ordered
+    expect(service).to receive(:send_confirmation).ordered
+    service.call
+  end
+end
+
+# BAD: Mocking the service you're testing
+RSpec.describe Orders::CreateService do
+  it "creates an order" do
+    service = described_class.new(params, user)
+    allow(service).to receive(:validate_inventory).and_return(true)
+    allow(service).to receive(:send_confirmation)
+    result = service.call
+    expect(result).to be_success
+  end
+end
+
+# BAD: Integration test disguised as a unit test
+RSpec.describe Orders::CreateService do
+  it "processes the order completely" do
+    result = described_class.call(params, user)
+    expect(result).to be_success
+    expect(Order.count).to eq(1)
+    expect(ActionMailer::Base.deliveries.count).to eq(1)
+    expect(Product.first.stock).to eq(8)
+    expect(user.reload.loyalty_points).to eq(10)
+    expect(WarehouseApi).to have_received(:notify)
+    expect(Analytics).to have_received(:track)
+  end
+end
+```
+
+## Why This Is Bad
+
+- **Testing method order is fragile.** Reordering internal steps breaks the test even if the behavior is correct. The user doesn't care if validation happens before or after order creation — they care about the result.
+- **Mocking the subject is circular.** If you stub `validate_inventory` to return true, you're not testing that validation works — you're testing that the service calls `create_order` after something returns true. The test proves nothing about real behavior.
+- **God assertions test everything at once.** When this test fails, which part broke? The order? The email? The stock update? The loyalty points? You have to read the failure message carefully and run the test in isolation to figure it out. Split into focused examples.
+
+## When To Apply
+
+- **Every service object gets its own spec file.** If you wrote a service, you write a spec. No exceptions.
+- **Test the `.call` interface.** Don't test private methods directly. Test them through the public interface. If a private method has complex logic worth testing independently, it might belong in its own class.
+- **Inject and double external dependencies.** HTTP clients, mailers, external APIs, other services — anything that crosses a boundary gets doubled.
+- **Test each outcome in its own context.** Success, each type of failure, and edge cases each get their own `context` block with focused assertions.
+
+## When NOT To Apply
+
+- **Don't unit test trivial services.** A service that wraps a single `Model.create!` call with no logic doesn't need its own spec. Test it through a request spec instead.
+- **Don't test private methods.** If you feel the need, either the private method is complex enough to be its own class, or you can test it through the public interface.
+- **Integration between services is tested in request specs.** The controller calls ServiceA which calls ServiceB — test this flow through a request spec, not by testing ServiceA's use of ServiceB.
+
+## Edge Cases
+
+**Service returns different result types:**
+Test each result type explicitly:
+
+```ruby
+context "when payment fails" do
+  it "returns result with :payment_failed error" do
+    result = described_class.call(params, user)
+    expect(result.error_code).to eq(:payment_failed)
+    expect(result.error).to include("card was declined")
+  end
+end
+
+context "when validation fails" do
+  it "returns result with :invalid error" do
+    result = described_class.call(invalid_params, user)
+    expect(result.error_code).to eq(:invalid)
+  end
+end
+```
+
+**Service wraps a transaction:**
+Test that the transaction rolls back on failure:
+
+```ruby
+context "when notification fails after order creation" do
+  before do
+    allow(notifier).to receive(:notify).and_raise(StandardError, "API down")
+  end
+
+  it "rolls back the order" do
+    expect { described_class.call(params, user) }.to raise_error(StandardError)
+    expect(Order.count).to eq(0)
+  end
+end
+```
+
+**Testing the Result/Response object:**
+If your services return a Result struct, test it as a value object:
+
+```ruby
+it "returns a result with the order" do
+  result = described_class.call(valid_params, user)
+
+  aggregate_failures do
+    expect(result).to be_success
+    expect(result.order).to be_persisted
+    expect(result.order.total).to eq(50.00)
+  end
+end
+```