For composed matcher, show the matcher is created where.
This may helps for user to troubleshoot.

Now, 1 example contains many matches.
It is a bit hard to read correspondences between codes and outputs.

Examples should be split by a match.

When scenario.Next is passed a variadic function, the returned function from .Next causes panic on invoking.

its/mocker can hide ...Impl or ...Behaviour.Mock from users.

Users get (almostly) done by only using ...Behaviours.

Of course ...Impl and ...Behaviour.Mock are the last resort to interact with them as a just function so such features are to be hold, but they should be "lower level API".

about Interface Mock

Now, its/mocker generates type ...Impl containing functions for each methods.

But, in the context of writing tests, it is needed that write types containing ...Behaviour types for each methods.
Because,

1. New...Call( ... ).ThenReturn( ... ) expresses requirements (New...Call) and conditions (ThenReturn) of a test, so that should be enough to state assertion, and
2. we cannot access t *testing.T during writing the test table of table driven tests, so we cannot New...Call().ThenReturn().Mock(t).

We needs ...Behaviour types for each interfaces. It should have a method like func (b SomeInterfaceBehaviour) Mock(t *testing.T) SomeInterface, as an analogy of ...Behaviour.Mock(t) for functions.

about Function Behaviour

During v0.2.x, its/mocker has came to expose ...Behaviour types for each functions or interface methods.

its/mocker/scenario requires us to write

sc := scenario.Begin(t)
defer sc.End()

// ...

... = scenario.Next(
  sc,
  gen_mocker.NewFooCall().ThenReturn(...).Mock(t),
)

However, this is a bit redundant. sc knows t since sc is created with t *testing.T.

If scenario.Next is specialized for ...Behaviour, that can be written like

sc := scenario.Begin(t)
defer sc.End()

// ...

... = scenario.Next(
  sc,
  gen_mocker.NewFooCall().ThenReturn(...),
)

Calling Mock is not needed. User can pass ...Behaviours in test tables to scenario.Next directly.

conclusion

By 2 changes above, users can

1. write {Interface}Behaviour having {Method}Behaviour in test table, and
2. during scenario tests, pass each {Method}Behaviours to scenario.Next directly

This may change its/mocker more handy.

probrem

When using generated struct spec & matcher, spec's filed is able to be nil.
In that case, matcher may cause SEGV since using nil matcher.

Fallback to Always by default.
This behavior may be changed by config package.

ClosedChan[T] is always Matcher[<-chan T].

However,chan T can be received. It should be tested with ClosedChan.
ClosedChan should be also Matcher[chan T].

map and slice matcher may same match rule for each want per elements.

Current style is too redundant. Add helper function or shorthand to be ease it.

mocker generates mock factory for type like func(privateType) (...) or func( ... ) (..., privateType, ...) .

Such mocks cannot be compiled and do not work.

Private-related mocks should not be generated.

Now, scenario.Next returns (token, trackedFunc) pair.

But currently, token is not used.

Remove such redundant return value.

We have string matcher, its.EqEq[string] for example.

But that is not enough to compare long text.
It may be nice when we have diffs of texts.

Currently mocker and structer is not useable when its is installed only.

To be useable, it needs importing mocker/structer directly.

Because, there are dependency, golang.org/x/mod, in mocker/structer but not in its core-part.

Add dependency to x/mod from core-part.

Currently, there are itskit.Property matcher.

This is useful for testing behavior of object, for example, "getter" method.

itskit.Property should be more easy to use.

There are its.Pointer.

its.EqEqPtr(want) is same thing of its.Pointer(its.EqEq(*want)).
its.EqEqPtr is not needed.

This is meta-issue to aggregate features for v0.2.0

To test of *T where T is a some struct, its should have a generic pointer matcher.

It may be a meta matcher like:

func Pointer[T any](m its.Matcher[T]) its.Matcher[*T]

slices and cmp is features introduced on go1.21.

To be compatible with go 1.18, remove uses of slices and cmp

motivation

Sometimes, it is need to notate that "mock function should not be called".

func TestFoo(t *testing.T {
  for name, tc := map[string]struct {
    condition bool
    mocked *FooBehaviour[...]
  } {
    "Foo will be called": {
        condition: true,
        mocked: FooCall(...).ThenReturn(...),
    },
    "Foo should not be called": {
        condition: false,
        mocked: nil,
    },
  } {
    t.Run(name, func(t *testing.T){
      sc := scenario.Begin(T)
      defer sc.End()
      foo := tc.mocked
      if foo != nil {
        _, foo = sc.Next()
      }
      Bar(tc.condition. foo)
    })
  }
})

If TheReturn returns pointer, I can write test as above. Intention of "should not call" can be expressed by nil-ness.

For methods of FooBehavirour taking pointer receiver, feeling of use may not change. Just it can be nil.

Support interface like

type I interface {
    OtherInterface
    Method()
}

Values returned from New...Call().ThenReturn(...) can not be set as test fixture.

We cannot do this:

type Case struct {  ... }

for name, tt := range map[string, Case]{
    "test case": {
        foo: gen_mocker.NewFCall(...).ThenReturn(...),
    },
} {
    t.Run(name, func(t *testing.T) { ... })
}

Since _[T]Behaviour, return type of .ThenReturn is not exported, we cannot declare a field typed _[T]Behaviour in struct Case.

its.Nil is creates its.Matcher[any] now.
But it is not useable to test that "an error should be nil", for example.

its.Nil should take type param.

func ExampleText() {
	its.Text(`
Lorem Ipsum:

    Lorem ipsum dolor sit amet,
    consectetur adipiscing elit,
    sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

    Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris
    nisi ut aliquip ex ea commodo consequat.
    Duis aute irure dolor in reprehenderit in voluptate velit
    esse cillum dolore eu fugiat nulla pariatur.

    Excepteur sint occaecat cupidatat non proident,
    sunt in culpa qui officia deserunt mollit anim id est laborum.
`).Match(`
Lorem Ipsum:

    Lorem ipsum dolor sit amet,
    consectetur adipiscing elit,
    sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

    nisi ut aliquip ex ea commodo consequat.
    Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris
    Duis aute irure dolor in reprehenderit in voluptate velit
    esse cillum dolore eu fugiat nulla pariatur.

    sunt in culpa qui officia deserunt mollit anim id est laborum.
    Excepteur sint occaecat cupidatat non proident,
`).OrError(t)
}

outputs

✘ (+ = got, - = want)		--- @ ./general_test.go:518
      |
      | Lorem Ipsum:
      |
      |     Lorem ipsum dolor sit amet,
      |     consectetur adipiscing elit,
      |     sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
      |
    + | nisi ut aliquip ex ea commodo consequat.
      | Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris
    - |
      |
      |     Duis aute irure dolor in reprehenderit in voluptate velit
      |     esse cillum dolore eu fugiat nulla pariatur.
      |
      |
      |
      |

• The first remove/insert pair (¶2, ll1..2) is dedented.
• After ¶2 l2, all lines are missing

It seems that this odd causes when at least 2 remove/insert pair appear in not continuous lines.

To test a func is invoked properly, mock is used.

Testing with mock is done by:

1. check arguments are ok
2. create (or inject) return value
3. check if the func has been called (in a exact order)

Its may be able to help users task 1.

• write a code generator which generates...
  • "argspec" (like structer's spec) from function arglist
  • mock function factory receives "argspec" and return value factory, that mock does Match() on invocation.

To do that, refactoring structer may be needed.