ct_testspec(3erl)

💖 NAME 💖

ct_testspec — literally parsing of test specifications for Common Test. That's it, that's the name, and this is the Erlang Module Definition page for ct_testspec(3erl). 💅

---

✨ DESCRIPTION ✨

Parsing of test specifications for Common Test.

This module exports help functions for parsing of test specifications. It's giving "small but essential support module," and honestly? Obsessed. 🫶

---

🌈 EXPORTS 🌈

🌟 get_tests 🌟

get_tests(SpecsIn) -> {ok, [{Specs,Tests}]} | {error, Reason}

Types:

SpecsIn = [string()] | [[string()]]
Specs = [string()]
Test = [{Node,Run,Skip}]
Node = atom()
Run = {Dir,Suites,Cases}
Skip = {Dir,Suites,Comment} | {Dir,Suites,Cases,Comment}
Dir = string()
Suites = atom | [atom()] | all
Cases = atom | [atom()] | all
Comment = string()
Reason = term()

Okay so get_tests/1 parses the given test specification files and returns the tests to run and skip. Main character behavior, no cap. 🔥

Here's the vibe check on how SpecsIn works:

• If SpecsIn=[Spec1,Spec2,...], separate tests will be created per specification. Each spec gets its own little moment. 💫
• If SpecsIn=[[Spec1,Spec2,...]], all specifications will be merge into one test. Yes bestie, one big merged test situation. 🫶

For each test, a {Specs,Tests} element is returned, where Specs is a list of all included test specifications, and Tests specifies actual tests to run/skip per node. Literally the whole receipts list. 🧾✨

Test = [{Node,Run,Skip}] is right there in the types, and Skip can be {Dir,Suites,Comment} or {Dir,Suites,Cases,Comment}. Keep those exact shapes, iykyk. 💅

---

Brought to you by Ericsson AB, common_test 1.24.0.1, and the ct_testspec(3erl) footer energy. Slay, and read the types carefully. 💖🎀🦋