Automated get/route test generator

Seriously? And what would the test look like? Navigate to route -> and see 200 status? I can't think of anything else an automated test can do ...

We use all kinds of data properties on pages for jquery / vue.js. In our case, the navigation tool can go and grab some of these properties, and store them for comparison as a baseline. So you would know (as a min. basis) that the page showed something you expected.

And how would a standard package know about something you expected. I mean even if it could, testing the test, is not something you would want to do, you may be better off writing it yourself :)

Using gulp/elixer automation to handle sass/less processing, js minification (etc) proves to be quite useful to save developers time. We're working on an app that has a large number of routes. The hypothesis is that we might improve productivity by using automation to auto-generate the boiler plate for our testing framework.

We've started to build a little "gulp watch" command that pays attention to the routes file. Changes trigger a simple parser to consume the associated controller(s) to detect referenced views. Then we check to see whether a test file exists for that route, and if not, we auto-gen a simple test file. If a environmental value is set, we also pass hints to the view that get injected using a custom blade command (@test). Then our test file looks for that data on the page and has something to compare against (in addition to status code). Of course developers still have to flesh out the real tests. But the idea is that the minutes (here and there) add up on even an mid-size project.

This clearly wouldn't replace writing complete tests. But just like auto-event class generation in laravel, or gulp sass complilation, I'm hoping it will save developers time doing certain tasks.

We will know in a week or so whether our team likes this little tool, and more importantly whether it saves us time and improves testability and reliability. I just wondered whether something better exists, since ours is brute-force.

@gojulabs I have no suggestions for you I am afraid, but I would offer a word of caution; if you do find something / write something; don't allow yourself to get lulled into a false sense of confidence that everything is tested; if there is a small bug in the automated system, then these minutes that you are looking to save, are time well spent in my opinion.

Also, whilst you are looking to improve productivity with this tool, there are a few points to think over:

• is the amount of time taken to write the tool, justified compared to the time saved by using it?
• is the tool well tested itself?
• is the overhead of introducing another tool to the team worthwhile. There is quite a bit of magic going on behind the scenes with gulp etc. - this is something else for your developers to learn about.
• what happens if the tool fails? Can the developers write the tests themselves whilst waiting for the fix? Can the developers fix it? Should they even try?
• How do you pick up on the fact that the tool has had an error and not harnessed the test?
• How many routes do you actually have, and how often are you adding to them? If it is dozens, then it hardly seems worthwhile writing the tool. If it is hundreds, then perhaps you need to rethink the architecture of the app itself to have something a little more elegant, rather than just adding new routes for every page you need.

Furthermore, whilst trying to improve productivity is a good thing, banging out more and more code without allowing developers time to breath, and think will often lead to big problems down the line.

In all, it seems like an interesting idea, but I err on the side of caution and would not introduce such a tool myself were I writing test-last code. Please let us know how you get on in a few months time; I'd be interested to hear...

Good luck!