testcomponents

package
v0.0.2 Latest Latest
Warning

This package is not in the latest version of its module.

Go to latest
Published: Mar 8, 2026 License: Apache-2.0 Imports: 2 Imported by: 0

README

Test Components

This directory contains components specifically designed for testing the nojs framework, separate from demo/production components in /appcomponents.

Purpose

Test components enable:

  • Integration testing of framework features (data binding, events, lifecycle)
  • In-memory testing without browser or WASM runtime
  • Full pipeline testing from template compilation to VDOM generation

Structure

testcomponents/
├── testrenderer.go           # Test harness for component rendering
├── databinding/              # Data binding integration tests
│   ├── Counter.gt.html
│   ├── counter.go            # Component (NO build tags!)
│   ├── Counter.generated.go  # AOT-generated (NO build tags!)
│   ├── counter_test.go       # Integration tests
│   └── README.md
└── README.md                 # This file

Test Renderer

testrenderer.go provides:

  • TestRenderer: Minimal renderer implementing runtime.Renderer interface
  • Captures VDOM output for test assertions
  • Uses shared vdom.VNode type (no duplication needed)

The test renderer implements runtime.Renderer interface:

  • RenderChild(key, child) - Renders child components
  • ReRender() - Triggered by StateHasChanged()
  • Navigate(path) - No-op stub for tests

Running Tests

# Run all test component tests
go test ./testcomponents/...

# Run specific package tests
go test ./testcomponents/databinding -v

# Run with coverage
go test ./testcomponents/... -cover

Adding New Test Categories

To test a new feature (e.g., events, lifecycle):

  1. Create a new directory: testcomponents/featurename/
  2. Add template: Component.gt.html
  3. Add WASM version: component.go (for AOT compiler)
  4. Run compiler: ../../compiler/aotcompiler -in .
  5. Add test harness: component_test_harness.go (for go test)
  6. Write tests: component_test.go
  7. Document: README.md

Build Tag Strategy

Latest Architecture: Unified Build-Tag-Free Components

As of the latest refactor, runtime.ComponentBase has NO build tags, which means component definitions no longer need separate WASM and test versions.

All core types are now build-tag-free:

  • vdom/vnode_core.go - VNode type (no build tags)
  • runtime/component.go - Component interface (no build tags)
  • runtime/renderer.go - Renderer interface (no build tags)
  • runtime/componentbase.go - ComponentBase struct (no build tags)

Generated code (e.g., Counter.generated.go) has NO build tags and compiles in both environments.

Component definitions (e.g., counter.go) have NO build tags and work everywhere.

Only WASM runtime implementations use tags:

  • runtime/renderer_impl.go (//go:build js || wasm): RendererImpl with DOM operations
  • vdom/render.go (//go:build js || wasm): DOM rendering via syscall/js

This represents a major simplification: one component file works in both WASM and test environments!

What These Tests Cover

✅ Template compilation (AOT)
✅ Data binding (struct → VNode content)
✅ Component lifecycle (StateHasChanged)
✅ VDOM tree generation
✅ Component state management
Shared generated Render() methods (no duplication!)

What These Tests Don't Cover

❌ DOM rendering (requires browser)
❌ VDOM diffing/patching
❌ Browser events (click, input, etc.)
❌ Actual HTML output
❌ CSS rendering

Future Improvements

  • Test VDOM diffing algorithm in isolation
  • Mock browser events for event handler testing
  • Test component lifecycle methods (OnMount, OnUnmount, etc.)
  • Test content projection (slots)
  • Test conditional rendering ({@if})
  • Test list rendering ({@for})
  • Auto-generate test harness boilerplate (struct + methods)

Documentation

Index

Constants

This section is empty.

Variables

This section is empty.

Functions

This section is empty.

Types

type TestRenderer

type TestRenderer struct {
	// contains filtered or unexported fields
}

TestRenderer is a minimal test harness that implements runtime.Renderer for in-memory testing without browser or WASM dependencies.

It captures VDOM output from component renders and allows tests to: - Attach components to the renderer - Trigger re-renders via StateHasChanged() - Inspect the resulting VDOM tree

func NewTestRenderer

func NewTestRenderer(comp runtime.Component) *TestRenderer

NewTestRenderer creates a test renderer attached to the given component.

func (*TestRenderer) GetCurrentVDOM

func (r *TestRenderer) GetCurrentVDOM() *vdom.VNode

GetCurrentVDOM returns the most recently rendered VDOM tree. Tests use this to inspect the component's output after renders.

func (*TestRenderer) Navigate

func (r *TestRenderer) Navigate(path string) error

Navigate is a no-op implementation for tests. Most tests don't need navigation functionality.

func (*TestRenderer) ReRender

func (r *TestRenderer) ReRender()

ReRender performs a re-render of the component. This is called by StateHasChanged() when the component requests a re-render.

func (*TestRenderer) ReRenderSlot

func (r *TestRenderer) ReRenderSlot(slotParent runtime.Component) error

ReRenderSlot patches only the BodyContent slot of a layout. For tests, this simply re-renders the slot parent component.

func (*TestRenderer) RenderChild

func (r *TestRenderer) RenderChild(key string, child runtime.Component) *vdom.VNode

RenderChild is a stub for child component rendering. For simple data binding tests, we typically won't have child components. If needed in the future, this can be expanded to track child instances.

func (*TestRenderer) RenderRoot

func (r *TestRenderer) RenderRoot() *vdom.VNode

RenderRoot performs the initial render of the component. This should be called at the start of a test to get the initial VDOM.

Directories

Path Synopsis

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL