CATCH needs a more searchable name

[vadz]

This is not the first time I run into this and I always just shrugged it off before, but after completely failing to find anything about the issue I was interested in (whether anybody has already done something to help with migrating the existing tests using CppUnit to CATCH) I have to say that this is a real problem: it's just impossible to find anything about CATCH using web search.

It needs to use some unique name or at least not a word so prevalent when speaking about unit testing in C++ (because I'm not interested in finding about how to catch exceptions in CppUnit, damn it).

It can be anything you like, I don't know if you prefer obvious but dull names (CppCatch, CatchUTF, ...), some other abbreviation (C++ Automated Tests Now Are Possible) or stupid puns (Notry, Dogch, ...) or hopefully something better I can't find, but it needs to be something you could enter into your search engine and actually find something related to CATCH.

[russel]

Catch works fine for me. Don't go with Catch++, trust me on this, I am associated with Zipios++.

I have never had a problem searching for things associated with Catch, as long as the word test was one of the search keywords.

[DarrenCook]

Russel, you probably read the manual once, and memorized it perfectly, so never saw the need to google "catch how to handle exceptions" like I just did :-)

Out of curiosity, I tried "catfish how to handle exceptions" to see how many existing pages to compete with. The top hit was actually for a (Python) library called Catfish: https://bugs.launchpad.net/catfish-search/+bug/1307126

The rest were all on fishing, as you'd expect.

[paolobolzoni]

catchthem :D a part that google "fixes" in "catch them" I find it easy to learn and it does not imply what you are looking for. A person? A bug? Something?

On Mon, May 25, 2015 at 3:32 AM, Darren Cook notifications@github.com wrote:

Russel, you probably read the manual once, and memorized it perfectly, so never saw the need to google "catch how to handle exceptions" like I just did :-)

Out of curiosity, I tried "catfish how to handle exceptions" to see how many existing pages to compete with. The top hit was actually for a (Python) library called Catfish: https://bugs.launchpad.net/catfish-search/+bug/1307126

The rest were all on fishing, as you'd expect.

— Reply to this email directly or view it on GitHub https://github.com/philsquared/Catch/issues/406#issuecomment-105046512.

[andybalaam]

catfish - OK, but different enough to lose a lot of momentum. catchtest - almost no loss of momentum. I think the downside @philsquared mentioned (people not changing to the new name) would be fairly temporary, and would be worth it to prevent disruption. You can bet stackoverflow would be up-to-date fairly rapidly.

[monocasual]

Just my two cents: C++atch :-)

[paolobolzoni]

Perhaps we should c...atch it out and let Mr Nash to think about it.

On Thu, Jun 4, 2015 at 4:36 PM, Monocasual Laboratories < notifications@github.com> wrote:

Just my two cents: C++atch :-)

— Reply to this email directly or view it on GitHub https://github.com/philsquared/Catch/issues/406#issuecomment-108766677.

[DavidEGrayson]

Maybe just call it "Catch Framework". That's what I type into Google these days to find it.

[rr-]

I'd say we're fine:

[vadz]

Searching for "catch" itself is not, and never was, a problem. Try searching for how to do something with CATCH, e.g. "catch check exception".

[nabijaczleweli]

Had I not known what Catch is, were I to hear about it in a C++ context, I'd search for "catch c++" or "catch library", both of which are on top.

[philsquared]

I've let this languish again - but since work is well underway on Catch 2.0 - which is going to be a big change - it seems like the right time for a name change too, if we're going to do it.

After a little time to look back I don't particularly like the name Catfish now (my previous proposal) - certainly not enough to lose the original "branding".

So my new proposal is simply:

Catch2

The 2 here is part of the name - similar to how the X in OS X, while pronounced "ten", and associated with the 10.x versioning, was part of the name. So it would start as Catch2 v2.0. Catch2 v3.0 might get a bit weird, but not a showstopper.

It has the advantage of being very close to the original - in a way that search engines should be able to allow for - while still prioritising exact matches. Plus it emphases that v2 is going to be a big break (in particular it's going to require C++11 and be substantially rewritten/ refactored).

Thoughts?

[nabijaczleweli]

[...] how the X in OS X, while pronounced "ten" [...]

Does _any_one actually pronounce it ten? I've only ever heard and used it as Ough-Ess Ecks

[philsquared]

If you hang out in Mac or iOS developer communities you'll hear most people pronounce it "ten" - also watch any Apple keynote that talks about it.

[philsquared]

Also, I think the proper "incorrect" pronunciation is, "Oh, Essex"

[nabijaczleweli]

If you hang out in Mac or iOS developer communities

I'd prefer to stay cancer-free, thanks

[rr-]

Catch2 is cool. @philsquared can we read somewhere about planned changes introduced by v2 (esp. the ones to public API / that are backwards-incompatible)?

OS X being an "OS 10" sounds pretty arrogant.

[mloskot]

On 5 July 2016 at 12:23, Phil Nash notifications@github.com wrote:

So my new proposal is simply:

Catch2 Plus it emphases that v2 is going to be a big break (in particular it's going to require C++11 and be substantially rewritten/ refactored).

Then, Catch11 :)

[philsquared]

@rr still working on it. I'm currently exploring the possibilities that the rebasing on C++11 allows. I'm going to write a blog post soon. Originally the headline features were planned to be: concurrency support and generators/ property-based testing. Both those features (especially the concurrency support) were key motivators in deciding that now was the time drop pre-C++11 support (Catch Classic will continue to be maintained with C++03 support - just no new major features). But the scope for internal clean-up with C++11 has me thinking (and toying with implementations) of the following:

1. Low std-lib dependency overhead for non-impl headers - including a custom String class. Idea is to address compile-time concerns.
2. Reworked expression decomposition, which allows for string conversions to only occur when needed (addressing some performance concerns).
3. New string conversions approach, which allows converters to be registered and discovered at runtime (reducing template machinery and coupling - as well as further reducing std-lib dependencies). Fallback of stringstream based conversions can be optionally disabled (to reduce those dependencies even more). The current approach also has a number of nasty order of evaluation issues.
4. Further reduced singleton surface area - with TLS caching of results to be merged in later made possible (for the concurrency support).
5. A more concrete, published, API for introspecting test case registry, current test info, etc.

In terms of breaking changes - despite the degree of internal rework I want to keep that to a minimum. The main areas will be around the use of strings - especially string conversions - which will use the new custom string type - as well as the new conversions framework. Reporters may be impacted too - but I may be able to provide an adapter for those (as I did with reporter interfaces changes when going to 1.0). It's possible the Session class may change too.

There's more but that's OTTOMH for now. Blog post to come.

[philsquared]

@mloskot

Then, Catch11

Actually there might be something in that! I had been thinking that Catch2 feels like it's just stopping short of Catch22 - but Catch11 is halfway there! :-)

[nabijaczleweli]

a custom String class

Phil y u do dis

[philsquared]

@nabijaczleweli several reasons, some of which I already hinted out. I'll go into it more in the blog post.

[martinmoene]

Looking at it this way the current Catch could be or have been named Catch98.

[martinmoene]

@philsquared Just to have it asked: could a minimal string_span (string_view) be of help?

"In case you missed it: string_view also in C++17", Herb Sutter, Trip report: Summer ISO C++ standards meeting (Oulu).

[vadz]

FWIW I don't think this is going to solve the problems which motivated me to open this issue. Whether it's Catch2 or Catch11 or Catch22, people will still refer to it as "Catch" for short and I don't think searching for it is going to work very well.

I still like the original CATFISH suggestion, but if you really want something even catchier, what about CATCHFISH. I'm sure someone will come up with backronym expansion for this if needed.

[russel]

I am sure the strapline "softly softly catchee buggy" indicates Catchee might work.

BTW next generation Catch will have to compete with RapidCheck for traction, property-based testing will become more important that example-based testing.

[philsquared]

@martinmoene actually it's a pair of String and StringRef I have in mind (where StringRef is similar to string_view) - both are quite minimal and are immutable. One advantage over std::string_view (other than not having to wait for C++17) is that you can usually get back to a String from a StringRef without copying.

[philsquared]

@vadz bear in mind there's no content (other than this page) for Catch2 in this context yet. I still think searching for "catch2" is going to get much more targeted results than "catch" currently does.

I do hear you about people still calling it just "catch" (one of the concerns I voiced before) but there's a fine line to be trod here - too different and we lose the association with "Catch Classic". Too similar and people will drop back to calling it just "Catch". Ironically the situation has become a classic Catch-22!

I'm still opening to further suggestions. Another possibility I've been toying with is "Recatch".

[philsquared]

@Russel yeah, PBT is certainly one of the big things I have in mind for Catch2. But bear in mind that this isn't really a competition. If people want to use RapidCheck then that's great! My original motivation with Catch was to provide an alternative that was easier and more fun to use than the alternatives at the time.

[martinmoene]

@philsquared Thanks for the explanation. (The word minimal meant to imply do-it-yourself w/o waiting for C++17;)

[vadz]

I think keeping the same prefix would be enough to avoid breaking the association with the current version, so I think anything starting with "Catch" (CATCHEM? CATCHUP? CATCHTOO? CATCHY?) would work. From this point of view, "Recatch" is not ideal, although it does seem appealing otherwise.

[philsquared]

@vadz that was my thinking with Catch2. Actually a quick search now (I use DuckDuckGo which shouldn't skew the results based on previous search history etc) confirms that catch+suffix returns far more relevant results than prefix+catch.

[philsquared]

... actually the search terms were "c++ unit test <prefix>catch" vs "c++ unit test catch<suffix>" compared to just "c++ unit test catch"

[GatoRat]

Why pull short with C++11? I've found that C++11 compliant compilers also support C++14 (and most of C++1z.)

[philsquared]

The very latest versions support large parts of C++14, yes - but even then is spotty - and only the latest versions (e.g. Visual Studio 2015, but not 2013) - whereas fairly good C++11 coverage has been around for a few years now - so even several older versions support it (although I don't think VS 2010 will keep up - not sure what the lower bound or gcc and clang will be yet).

I would love to use C++14 (17 even more so!), but most of what I would use it for here is minor convenience - compared to the night & day difference between 03 and 11. In the code I've written so far I'm not sure a single line is valid C++03 ;-)

[jmcarter17]

My 2cents (For what it's worth)

When you proposed catch2, I immediately thought of Catch 22, which may or may not be bad. Catch11 is great, and it gives you an obvious renaming path for future releases that will require a change in the standard. Catch23 would obviously mean you need a C++23 compliant compiler ...

Anyways, I'm glad that you are reopening this issue because I have had problems searching for catch solutions in the past.

I'm fine with catch2 or catch11, but people will definitely keep calling it catch.

[ryanpfeeley]

My two cents Re the original issue: philsquared is so prolific, that using "philsquared" in place of "catch" in any search query is bound to get you exactly want. Now perhaps that doesn't scale to the future since it isn't part of the brand, but steering searchers to include your handle might give you a little flexibility as you rebrand. If the biggest break is compiler dependence, using catch11, catch17, is ok. People will definitely keep calling it catch though. Embrace success!

[horenmar]

I am going to close this in favor of #769, where we can also discuss the name of the upcoming rework.