Developer Guide: sprtt Package

Meike Snijder-Steinhilber

2026-01-22

Overview

This vignette provides technical documentation for developers who want to maintain, extend, or contribute to the sprtt package. It explains the internal architecture, code organization, computational methods, and development workflows.

Target audience: R package developers, future maintainers, and contributors

Prerequisite knowledge: - R package development basics - S4 object-oriented programming - Statistical knowledge of Sequential Probability Ratio Tests (see vignette("sprts"))

Package Architecture

Overview

The sprtt package follows a modular architecture with clear separation of concerns:

1. Main User-facing functions (seq_ttest(), seq_anova()) handle input validation and provide clean interfaces
2. Utility User-facing functions provide supporting functionality (plotting, data generation, caching)
3. Builder functions (build_seq_*_arguments()) Transform and validate user inputs into a structured S4 argument object. Builder functions act as a processing pipeline between the user-facing interface and the core calculation functions. They handle the complex task of parsing different input formats, validating all parameters, and packaging everything into a type-safe container.
4. Calculation functions (calc_seq_*()) perform the core computations
5. Internal utility functions (e.g., delete_na(), extract_formula(), get_seq_decision(), …) are small, focused helpers that handle specific tasks across the package. They follow the Single Responsibility Principle - each function does one thing well. This design reduces code duplication, improves testability, and makes the codebase easier to maintain.
6. Result Classes - S4 classes that store results in type-safe, structured containers. These classes provide controlled access to result components through standardized methods (@, [], and show()), ensuring consistency and extensibility.

This separation allows for: - Easy testing of individual components - Clear error handling at appropriate levels - Extensibility for future sequential tests - Consistent user experience across functions

Function Naming Convention: - seq_*(): User-facing main functions - build_*(): Argument preparation functions
- calc_*(): Computational core functions - *_class.R: S4 class definitions

Function Structure

Table: Structure of the main seq_ttest() function (Level 1)

Level 2	Level 3	Level 4
build_seq_ttest_arguments()	check_formula()
Class: seq_ttest_arguments	extract_formula()
	get_one_sample()
	delete_na()
	check_data()	check_constant_data()
calc_seq_ttest()	calc_seq_ttest_t_statistic()
Class: seq_ttest_results	calc_seq_ttest_non_centrality_parameter()
	calc_seq_ttest_likelihoods()
	calc_seq_ttest_boundaries()
	get_seq_ttest_decision()
	build_seq_ttest_results()

Table: Structure of the main seq_anova() function (Level 1)

Level 2	Level 3	Level 4
build_seq_anova_arguments()	check_formula_anova()
Class: seq_anova_arguments	extract_formula_anova()
	check_data_anova()
calc_seq_anova()	ANOVA-specific calculations
Class: seq_anova_results	calc_plot_anova()

Table: Structure of the main plan_sample_size() function (Level 1)

Software Testing

Continuous Integration

GitHub Structure

Release Checklist

Pre-release

• Update version number in DESCRIPTION
• Update NEWS.md with all changes
• Run devtools::check() - must pass cleanly
• Update documentation: devtools::document()
• Rebuild vignettes: devtools::build_vignettes()
• Test on multiple platforms (rhub, win-builder)
• Update README if needed
• Check all examples run correctly
• Verify all URLs in documentation are valid
• Run code coverage: covr::package_coverage()
• Update copyright year if needed

CRAN Submission

• Prepare cran-comments.md
• Submit to CRAN: devtools::release()
• Monitor email for CRAN response
• Check CRAN package page after acceptance

Post-release

• Create GitHub release with tag
• Tweet/announce new version
• Update pkgdown site: pkgdown::build_site()
• Increment development version number
• Update NEWS.md with “Development version” section

Contributing

How to contribute: 1. Fork the repository 2. Create a feature branch 3. Make changes with tests 4. Submit pull request 5. Respond to review comments

Contribution guidelines: - Follow existing code style - Add tests for new features - Update documentation - Keep commits focused and atomic - Write clear commit messages