Develop Reference

How to test a series of interactions?

I've been learning how to write automated tests for a React app, and it's brought up questions on how best to test a series of interactions with the app.
Let's say that I have a React app that allows the user to assign students to seats in a classroom: Here's an image of what such an app would look like.
I'd like to test creating a new student, adding that student to a seat in the classroom, and then moving that student back to the area of unseated students in the middle column (I'll call it the roster).
What would be the best way to write out the test(s) for this? Would it make sense to have a single large test case, which would include assertions for each of the interactions I'm testing (creating a new student, moving it between the classroom and roster)?
Or should I create multiple cases, where one depends on the other? In other words...
Test 1) Check that a new student is created successfully when submitting the form
Test 2) Using the student created in test 1, move the student to a seat in the classroom
Test 3) With the student now in a seat (due to test 2), move it back to the roster area
Another question I have is whether React Test Library would be sufficient for this purpose. Or would this be considered an end-to-end test that should be written using Cypress?
Your feedback is much appreciated!

The process you described can surely be tested with react-testing-library as an integrated test. From the docs/faq, it encourages testing a component high enough up the component tree, without mocking child components, in order to simulate and test what an actual user interaction would be like.
Also check out this Kent C. Dodds blog post .

You want your tests to be as granular as possible, as you have already split them in 3 different cases. This will make it easier for everyone to read your code.
As for the testing library, I would go with Cypress which advertises itself as a JavaScript End to End Testing Framework.
You are testing end-to-end functionality here by manipulating what seem to be multiple components. React testing library, on the other hand, seems to focus on testing individual components on a more low-level approach - there's a chance it will falter on the long run, but it probably gets the job done aswell.

Typesafety in javascript or how to avoid pretty hard to detect type related errors

I come from the Java world, i.e. a typesafe world and am right now doing a couple of things for which I need client side execution using javascript.
I keep running into pretty hard to detect errors at times due to the non typification of JS and am wondering if there is any way to prevent it beforehand. E.g. setting sth like "use typification;" or via some tool that does these checks before executing like a compiler does.
E.g. last time was when I was creating a face in three.js. There depening on order of vertices a face is front-facing or not. I had mixed that up and then copy pasted parameters in which case I also copied a bracket too much so it ended up in the wrong place with just calling the method with one instead of three vertices which of course resulted in an error. However in line 2107 of three.js code and it took a while to figure out this little copy paste issue. Comparing to java the compiler would have directly complained that i try calling the method with 1 instead of 3 parameters...
Hope there is sth like it. Or do have some tips how to spot such things faster?
Cheers
Tom

There are various linting tools which you can use to scan your javascript files before you actually use them. The popular ones in the industry are JSLint, JSHint, JSCS and ESLint.
They come inbuilt with various rule sets which you can configure and you can also add your own rules.
You can compare these to checkstyles and PMD from the JAVA world.

You have a number of answers. But first, need to clarify: Java is not type-safe (see: NullPointerException, history of).
But to get closer to type-safety in any dynamic language you have the option to pepper your code with asserts. This can to some degree be automated, it may cause performance issues. This is the route I usually take, but I certainly wouldn't do it with three.js.
For JavaScript specifically, you have two additional options: TypeScript and Flow.
TypeScript is a dialect of JavaScript with type annotations that gets compiled down to plain JS. Flow is a static analyzer written in OCaml that tries to infer types in your JS code and check them.

How to remove JS logging calls in our prod build of our mvc3 web app?

We've got a lot of calls to our logging methods (that just wrap console.log) all throughout our JS in our MVC3 web app and I'd like to remove them from the JavaScript when we build our test and production builds.
Currently we're using the bundling and minification nuget package to bundle and minify our JS into one big minified file but I'd like to have it rip out the calls to the logging methods as well.
We do have a mechanism in place that replaces the logging methods with empty functions so they won't do any work in production, but they are still called and various arguments are passed in. On top of this, there are "large" strings that are passed and those could be removed, reducing filesize.
The ideal solution in my mind would be to somehow parse the JavaScript and detect / remove the calls to those methods. Preferably in some sort of JavaScript engine and not just a regular expression.
Either way, I just want my calls to my logging methods removed in the final JavaScript that is served up in production. Does anyone know how I'd accomplish this additional minification?

Yep, the IBundleTransform interface was designed for this scenario. In RC bits here's what we envisioned:
new Bundle("~/bundles/js", new LogRemoverTransform(), new JsMinify());
Basically, you construct a bundle and chain two transforms, first stripping your log methods, and then running through normal minification. Prior to RC, you would have to do the composition inside of your IBundleTransform.

You could write your own implementation of IBundleTransform that first removes calls to your logging methods via a regular expression and then calls the default bundling and minification functionality. As long as your calls are fairly simple, it shouldn't be hard to come up with. It might get tricky though, depending on how you call your logging code.
For example, it'd be fairly hard (for me) to build a regex that would catch the entirety of a logging call like this:
NS.log(function () { return "this is going to be hard to parse"; }());
But, as long as you don't log like that, it shouldn't be a difficult regex to write.

Why use CakePHP's JsHelper?

I'm just starting with CakePHP and was wondering if someone could explain the true benefit of using its JsHelper over coding regular static jQuery and JS. So far, I don't really see how the helper would make creating scripts easier or faster.

for the same reason I wrote my GoogleMaps Helper ;)
the basic idea is that you can use the same language (php in this case) as the rest of the application and you can pass in any php option arrays and arrays holding data values and the helper is supposed to cake care of it.
it is similar to cakephp as a wrapper for php. it wraps your code and can help keep it dry.
don't get my wrong - i never ever used the js/ajax helper myself.
but I can understand why some want to chose it over writing JS themselves.
in some cases the output can even be more "correct" (if you don't know about the potential problems). for example the IE bug:
if you output {} options yourself and forget to remove the last , it will not run in IE6 etc. that can't happen with the helpers as wrapper - at least it shoudnt ;)
so with the helper it either doesnt run at all or runs as a team of skilled developers designed it to work.
especially for not so skilled developers this is usually a win-win situation: fast and more reliable. you can always start to switch to manual stuff later on (if you see the actual JS output and start to understand it).
also - when any of the js methods need to change for some reason your way of using the helper usually doesn't. if you don't use the abstraction you might find yourself in the need to manually adjust all occurrences.

As like any Helper, the JsHelper is a way to parse stuff into your view in a simplified way. But putting in "raw" JS/jQuery code into your view would work just fine by using $this->Html->scriptBlock for example.
There is not a real benefit I could think of other than if jQuery would ever change the syntax of a specific function, you wouldn't need to adjust your code when using the JsHelper, since the core then needs that update to be implemented, rather than you having to change all your "raw" JS code throughout all of your views.

JsHelper is like scaffolding: comes very handy if you need just the basic stuff, and only the basic stuff. That is, ajaxify a pagination or some elements.
But beyond that, it is better to write your own code, because you will need things as you need them, and not how the helper is aligned by default.
As everything else in a framework: it is a tool. Check your requirements and use the best tools available.

Test sorting with Cucumber and Capybara

Is there a way to test sorting of a list with Cucumber and Capybara. The sorting is done client-side with javascript.
I was thinking something along the lines of:
Then I should see "first element" and then I should see "second element"
Unfortunately I have no idea how to approach building the steps.
Thanks for the help!

It's a good idea to separate out the stories that you're testing (which you want to get close to plain English) and the actual implementation of the testing (which is hidden in the step_definitions).
There are a few ways to tackle this, depending on what you want to test. In the first case, the cuke test is very readable, and it boils down to implementing the step definitions correctly:
Given that I am on page xyz
And I have a list
Then I should see the list in sorted order
In this case, you'll have to define what it means to have a list (can assign it to #list in a step def if you want), and then what it means to see the list in sorted order (here you can pass a regex that ensures you see item 1 before item 2, etc.)
Alternatively, if you like being more verbose in the cuke tests, you can do something like like:
Given that I am on page xyz
Then I should see /item1.*item2.*item3/
which assumes the list is already populated.
Depending on where the list is, you may have to use a within scope param.
Remember that cucumber is great for functional and integration testing, but probably isn't the right tool for unit testing the sort (looking at all edge cases). To test the sorting at a unit test level, I'd highly recommend using QUnit. Since QUnit tests are static pages, try this trick for running the tests as part of capybara:
Given I am on "/test/path/to/qunit/tests"
Then I should see "Whatever Title You have Assigned"
And I should see "0" within "//p[#id='qunit-testresult']/span/[#class='failed']"