@Cenay Bit late to this thread, but wanted to add some advice which will be useful, not just for this, but testing in general, which will hopefully build very well on what @96downlu has already put forward.

A big mistake often made is that developers feel they are writing tests to 'test the code', which can be partially true, certainly for low level unit tests, but isn't always the best way to think about it when approaching the questions of what to test, how to break it down etc.

I always advise people to actually think that when you are testing anything, think of it from the angle of not testing code, but testing (required) behaviour... and this is absolutely the best way to approach testing an application already in use.

Fundamentally, tests should define what the application does, how it works, what you can do with it, and what it does for or gives you.

The best place to start would be to actually 'define' the application... break it down into feature areas (auth, posts, announcements, notifications, mail etc etc.), then set about the available api & behaviour for those features. An example would be it('allows a users to be created), it('allows a user to update their profile) etc etc. and don't forget that in PEST, you can actually do this with the test todo logic explained in this vid ;)

Once you have this set of definitions, you pretty much have your basic, top-level set of tests. From there you can start to expand on those initial tests with what I always refer to as conditional enforcement tests, i.e. it('prevents users from being created without an email) or it('ensures all created users have an email') depending on which way you test, being the negative or positive enforcement.

From here, you not only have the applications features tested from a minimal behaviour point of view, but you now also have the applications resilience and self-protection started to be tested.

After this, you can keep expanding, and also start to look at lower-level unit logic tests, such as custom helpers and objects... normally we would address these first of course as they were created, but likely if the existing app isn't tested, then likely they wouldn't be either. Testing them after the tests are written for the feature is acceptable, as they technically would get coverage where used in the application via the application tests... from a failure perspective anyway.

Hopefully you got there, and if not started or not completed, then I hope this helps... or of course helps anyone else that comes along :)

Coverage and Parallel