Cannot recognize blocTests

[avatarnguyen]

This plugin won't recognize blocTest, f.e this one:

    blocTest<AuthBloc, AuthState>(
      '''
SHOULD emit [AuthState] authenticated after AuthenticationStatus changed to authenticated
      ''',
      build: () => authBloc,
      act: (bloc) => ...,
      expect: () => [
        ...
      ],
    );

I am wondering whether this could easily be fix by adding blocTest to line13 in file lsp_outline_parser.lua ?

 local _, _, test_name = element.name:find('[testWidgets,test, blocTest]%("(.+)"%)')

[sidlatau]

There are two ways in this plugin how test information is obtained. First, it tries to parse the file with Treesitter. When LSP server attaches, it tries to get information from the outline (the outline solves some problems with more complex test names).

I am not using bloc_test so not sure if this method is visible in the outline. If yes, then PR is welcome with the proposed update. If not, then we may fallback to Treesiter, here is a relevant line: https://github.com/sidlatau/neotest-dart/blob/f404d558c0ef8a463bf2b9882b6116b6b2301030/lua/neotest-dart/init.lua#L50 Also, I saw there is now a third option - run test by line number: https://dartcode.org/releases/v3-64/#testing-improvements - that also may be investigated if the proposals above will not work.

[avatarnguyen]

• The first approach with lsp_outline_parser.lua didn't work.

• 2nd approach with Treesitter is not working perfectly.

  (identifier) @testFunc (#any-of? @testFunc "test" "testWidgets" "blocTest")

the test is recognized and in success case the test also run through. But when I change my bloc test to a faulty one, it run until timeout and didn't display a correct error message.

[sidlatau]

I added the ability to configure custom test method names. Please try to add custom_test_method_names = {'blockTest'} to your config, that may help.

In general, it is not an ideal solution. LSP outline already provides all the needed information, it should be enough to mark a method with @isTest annotation. That's how VSCode works. I think it should be possible to implement this behavior in this plugin too, but that requires bigger refactoring.