Add module tag to elixir test cases

[jiangphcn]

Overview

Some elixir test cases don't have actual module tag. Add tags to help include or exclude them in CI test.

Testing recommendations

make elixir

Related Issues or Pull Requests

Checklist

• Code is written and works correctly
• Changes are covered by tests
• Any new configurable parameters are documented in rel/overlay/etc/default.ini
• A PR for documentation changes has been made in https://github.com/apache/couchdb-documentation

[dottorblaster]

We already did a bit of categorization with @iilyak, :cluster and :single_node for example were meant for that purpose 😅 Maybe we need to put up a stronger naming convention?

[jiangphcn]

The kind related tag is still kept. We just want to add new module tags to give fine-grained classification for elixir test cases.

[jjrodrig]

It's ok for me

I've been porting some of these tests and I found difficult to define a meaningful tag that helps to categorize tests.

[dottorblaster]

As long as it is ok for JJ, then it's ok for me 😄

@iilyak please take a look at this and tell us what you think, maybe some sort of stronger and more fine-grained naming convention would be useful, I'm very interested in your opinion

[iilyak]

I've noticed that most of the tags in this PR ended up to be unique ones. The only exceptions is docs which I bet used somewhere else. This means the granularity level is a single module. I am not sure it useful to do it by module. We can run tests for a single module already. We also can run tests for list of modules as well:

make elixir tests=test/elixir/test/basics_test.exs,test/elixir/test/replication_test.exs,test/elixir/test/map_test.exs,test/elixir/test/all_docs_test.exs,test/elixir/test/bulk_docs_test.exs

I think the better grouping would be based on the big features of CouchDB we intend to test. Let's say a developer is updating the view engine. In this case he/she would be interested in running all tests for view functionality. Because changes in that area might break related functionality. So I propose to look at tagging using following heuristics (just an idea and subject for discussion):

• tag which is set on a single module is an exception not a norm
• think about what component (or feature) of CouchDB given module tests to come up with a tag
  • we can use cover information to assist as initially but it could be an overkill
• determine where (in which erlang application) the endpoint we test from given test module is handled and tag after application name (mango, mem3, setup, deyfus)

  find src/ -name '*_httpd_handlers.erl' | xargs grep '_handler(' | grep -v no_match |  cut -d':' -f2
  url_handler(<<"_membership">>) -> fun mem3_httpd
  url_handler(<<"_reshard">>) -> fun mem3_reshard_httpd
  db_handler(<<"_shards">>) -> fun mem3_httpd
  db_handler(<<"_sync_shards">>)   -> fun mem3_httpd
  url_handler(<<"_cluster_setup">>) -> fun setup_httpd
  db_handler(<<"_index">>)        -> fun mango_httpd
  db_handler(<<"_explain">>)      -> fun mango_httpd
  db_handler(<<"_find">>)         -> fun mango_httpd
  db_handler(<<"_index">>)        -> fun mango_httpd
  db_handler(<<"_explain">>)      -> fun mango_httpd
  db_handler(<<"_find">>)         -> fun mango_httpd
  url_handler(<<"_search_analyze">>) -> fun dreyfus_httpd
  db_handler(<<"_search_cleanup">>)  -> fun dreyfus_httpd
  design_handler(<<"_search">>)      -> fun dreyfus_httpd
  design_handler(<<"_search_info">>) -> fun dreyfus_httpd
  ...
  

[iilyak]

JFYI: It is also possible to run individual tests within the module

make elixir tests=test/elixir/test/basics_test.exs:155

[iilyak]

There is nothing wrong with this PR. I don't mind having extra tags if folks find it useful.
We can do other round of classification as a separate PR.
+1

[jiangphcn]

thanks to all of you, @dottorblaster, @jjrodrig and @iilyak. Let me merge for now and we can make further classification later.