A quick disclaimer: I am not having issues, I am simply asking for guidance. I don't feel like the other topics provide a guiding point towards a particular style of testing or library rather than just helping other with their actual choice of library and style.
Hey guys! I was thinking, is there anyone in here that could provide me with some guidance for unit testing? What kind of testing do I want (I am a newbie)? e2e, tdd, bdd etc.? Any particular recommendations for libraries and good practices? I am currently working on a React Redux-Saga project and a node backend that we'd like to start testing as well. Is there library that we can use for both or do we need two different since it is essentially two different projects (Client, Server).
There are plenty of test runners out there, I would recommend using Jest its easy to setup full featured and has good documentation and maintained by Facebook. Enzyme is the de facto standard for parsing react components and traversing the DOM, although is just a wrapper around Reacts native test utils.
https://facebook.github.io/jest/
https://github.com/airbnb/enzyme
You don't need different testing libraries for client and server code at a unit level. Although for end to end testing / integration testing you do need a different runner generally one that includes selenium, although there are some great alternatives out there at the moment.
Here is a doc I put together outlining some React testing fundamentals
cypress.io looks like an interesting new platform for writing end to end test without the need for selenium making it faster and more stable.
jest is a very good option if you're working with both nodejs and react.
For a good practice, I would recommend trying to apply Clean Architecture so that your source code will have good separation of concerns and testability.
Related
I come from a decade of experience with Java EE, SE and Java with Spring. If there's something that was drilled in me by myself and other fellow developers, was how to make use of design patterns, separation of responsibility, separating definition from implementation, interface segregation, etc. Also, we were always worried about testable code (unit testing and integration tests).
When I was learning Java, there wasn't a single book, magazine or website that didn't implemented things with those rules in mind, to the point of boredom. So we always new how things should be done from an architectural point of view when starting new stuff or maintaining code. With time, projects like Spring Boot and JBoss Seams started to give out of the box a basic project layout witch you simply followed to success(or at least you should...).
Now that I delve deep in Node.js, I miss that so much. There seems to be only a handful of people on the web worried about it and trying to teach newcomers how to write good backend code with Node.js.
People teach you how to boot express and put all of your code (database, logging, mailing, error handling and so on) inside an express route.
Of course, when I started learning Java, there was nothing preventing you from using Servlets directly with some JDBC code thrown inside, or even worse, Scriptlet inside JSPs...
I would appreciate so much to know how you for instance implement a service layer, where do you put your business logic? Do you put it in classes or functions that returns other functions? How to write easily testable code by Mocha for instance... Do I really need a controller layer, or can I trust my routes to cover that responsibility?
I'm interested in JavaScript only on the Backend, using Express.js, Socket.io, RabbitMQ, Passport.js, and GraphQL(in the future). Not interested in any rendering engine or template engines, much less JavaScript on the Browser. I'm already very proficient with Sequelizer and Mongoose.
I know the feeling of switching from Java Spring Boot to the Node.js stack. It was confusing for me in the beginning aswell, but with time you find your set of frameworks you like.
I'm probably not qualified enough to answer your entire question, but I can give you some advice of what framework helped me the most after starting with Node.js.
For me, this framework is NestJS.
It's a progressive Node.js framework to build scalable server-sided applications, based on Express.js. It supports a lot of different design patterns, but I personally use a pattern consisting of controllers, services, repositories and providers. You can use multiple different databases obviously.
Nest.js stands out for me, because you don't need any 3rd-party tutorial or documentation, because their own documentation is done really well and has basically all the information you'll ever need. It is really expandable with additional dependencies (most of them are in-house developed and have great documentation aswell).
What also has to be mentioned, is that as a Java-dev you will probably miss OOP if you switch to JavaScript. In Nest.js tough you only develop with TypeScript and overall it gives you a feeling very similar to Java Spring Boot.
I really want to start learning Angular2 but the thing is I don't like the idea of having typescript. I want to do it using pure Javascript. But it seems like there is no proper documentation made for it. Do you have any recommended links where I could start with? 2nd question will be: Is it really worth learning Angular with Javascript since it has no docs for it? Or should I just embrace Typescript?
Or should I just embrace typescript?
Yes.
As a practical matter, you are going to find very few, if any, code examples, gists, tutorials, or blog posts that describe Angular without using TypeScript.
The reason is that 95%, or probably more like 99.9%, of Angular users are using TypeScript. That is because it brings a lot of benefits with very few drawbacks. You should re-examine your reasons for not liking the idea of having TypeScript. Yes, there's a learning curve, but it's also an investment in your future, one that will start paying dividends from day one in the form of improved productivity and code quality.
The only really compelling reason for trying to use Angular from JavaScript is if you want to use some subset of Angular's functionality, such as perhaps DI, from a non-Angular application.
It is possible to develop an application with ES5, ES6 or ES.next (transpiled with Babel). The difference between them and TypeScript is how DI and modularity are implemented. This example shows how it's done. And this document in Angular 2 documentation explains the differences.
JavaScript is currently considered second-class citizen in Angular development.
Almost all learning resources use TypeScript, which is not a problem if a developer knows how this code translates to JavaScript; the conversion involves the removal of types and refactoring DI annotations. If a developer doesn't use Babel for transpilation, he/she should be aware of modern JS features that are supported by TypeScript but not target browsers.
The problem is that JavaScript isn't supported by official Angular CLI tool and Ahead-of-Time compilation. This seriously limits the usage of Angular JavaScript applications in production.
I'm adding another answer here with some real technical points.
It is possible to get something running using JavaScript and not TypeScript. But you will have two major problems which mean you shouldn't do it:
You will need to do a lot of configuration. Here is a good article explaining how it can be done, but you'll have to make some changes to get it working with the latest version of babel and webpack, which is not trivial.
You will never be able to get the production bundles down to a sensible size. This is because you won't be using the angular-cli to do your builds, but will instead be using purely webpack. angular-cli appears to do some intelligent building with webpack and the typescript compiler to output much smaller, production bundles. For this reason alone, it's a non starter. The smallest bundle I've managed to get for a hello world app is over 800kB. The equivalent app built with typescript is about 140kB.
I feel that the angular team should update their documentation to point this out.
I'm starting to delve into some work with JavaScript and i'm trying to get a feel for how I should be writing testable JS code. My background is primarily Java which i'm quite comfortable with but I have no JavaScript experience. after some reading, I was going to use js-test-driver as my unit test framework, but I am open to suggestions here as well. With Java, my approach has always been breaking things down into small methods which accept something and return something... With JavaScript, I figured I would take a similar approach by separating any DOM manipulation and the actual logic into 2 separate functions. For example:
function sumValues(valA, valB) {
return (valA + valB);
}
function displayResult(result) {
document.getElementById('result').innerHTML = 'result';
}
So, any business logic would be easily testable.
Am I on the right track here or is there a better way to do things? Any recommended reading on this topic that is JS specific? Thanks for any ideas
Breaking code into logical units still applies in JavaScript of course. As to how exactly you'd structure your code and organize reusability, there are many different ways to choose from - too many to list here and also a matter of personal preference. From prototypal inheritance, to pseudo-classical inheritance; using frameworks like backbone.js, angular.js, require.js, yui, google closure...
Regarding your example you'd probably start separating your code into views and controllers which are testable separately, and have only the view manipulate the DOM. I'd check out backbone.js for more.
A book that really helped me get started with test driven development in JavaScript (and also learn about JavaScript at the same time) is Test-Driven JavaScript Development by Christian Johansen.
I'm using JsTestDriver, it's a great software and definitely good to use. But before using it large scale I'd evaluate other products too, because development in JsTestDriver has been going really slow recently.. Buster.JS looks promising. Another interesting runner is Testem which allows you to use different test frameworks, like Mocha and Jasmine.
I can also recommend Sinon.JS as mocking toolkit.
At the moment I'm working on a JS library for a webservice, you can compare it with Twitter Anywhere. Now i want to make it more test-driven.
It's not easy to test because it has to work on every site that wants to make use of it, and of course with every browser.
How can i test the library efficiently?
All the API requests and responses are in JSON, is there a good way to test these calls?
I know about Cucumber and js-test-driver.
Greetings,
Chielus
Javascript language is dynamic by nature, so it is really test-driven friendly. I've recently got a little experience with javascript testing. I've rewrote major javascript components using TDD and got clear desing and more compact code!
unit test framework of choice is qUnit. It is very easy to start with testing.
functional test framework of choise is funcunit.
I did a blog post of testing REST api with FuncUnit here.
If you need some examples of tests and implementation, you can check my github repository.
Don't ask questions, just start testing :)
If you know about jsTestDriver I think you've already found a good solution?
You can use it to automatically launch your tests in multiple browsers and return success or failure.
This sets it apart from other tools that use headless browsers, as with jsTestDriver you're running your tests in real browsers, which seems to meet your requirements.
jsTestDriver comes with its own limited assertion framework but you can plug others into it including QUnit, YUI and Jasmine.
You said above in relation to Jasmine, "I don't think i can do BDD, because it's a library that has to work with all kinds of sites.". I'm not sure what you mean by this?
Jasmine provides all the assertions to let you do the same tests as QUnit. It also lets you 'spy' on Ajax callbacks, intercept the JSON to examine or even alter it, then pass it on to your default callback. With this you could check the JSON response then check again when your UI has reacted to it in the right way.
I'm about to write a simple HTML5 + JavaScript (jQuery) app in my spare time in order to keep up with the latest web technologies (at work it's more advanced C# backend stuff).
I'd like to develop in the same fashion that I've done for the last ten years or so, namely TDD style.
Being new to the TDD/BDD/AcceptanceTDD world in HTML/JavaScript, my question is: is there a great framework or the like for writing test against a web page in a browser (out-of-the-box support for many browsers being a definitive plus)?
The reason I'd like to use JavaScript is two-fold. 1. I'd like to learn more JavaScript, and 2. I'd like to use the same language(s) for the tests as I do for development.
Otherwise, I could simply use my C# skills and use Selenium, WatiN, or a similar framework.
I've found Jasmine, QUnit, and a homegrown solution using jQuery at MSDN, but don't get a feel for the flow nor complexity, so recommendations and first hand experiences are more than welcome.
JS Test Driver is the framework recommended by the Javascript TDD book from O'Reilly that I'm reading right now. I haven't actually had a chance to play with it much yet, but:
A dude who wrote a book on JS testing recommends it
It has a very nice feature set (automated test running across multiple browsers being key)
It comes from Google (love 'em or hate 'em, they have a lot of smart JS people working there)
So at the very least it's worth checking out I think.
At this point, I'd recommend Jasmine. I've used it successfully on a few projects. I haven't really run up against too many frustrating situations where I just couldn't get something done (unlike other tools). It can be set up in different configurations, depending on your preference-- it can be as simple as opening a page in a browser, or it can be "served" dynamically.
There are dozens of tools out there in general usage-- and so far-- no clear winner. I've tried a quite a few of them, and-- as John Resig points out-- creating a simple testing framework isn't that complicated. But adding some tools to make it convenient is important. Jasmine is the most complete one I've used, but it's not bloated.
Important considerations:
set up: don't adopt a tool that doesn't work easily out of the box
style: use a tool that makes sense to you in the context of the rest of your testing tools. For example, if you use BDD tools, find a BDD Javascript framework. This is probably the biggest variance in the frameworks-- might as well pick one that has a syntax you like.
cross-browser: the tests should work across browsers
automation: you should be able to script the running of the tests in one or multiple browsers
testing time-based code-- if you Javascript has behavior tied to the clock (as in animations), having a testing framework the facilitates this is nice
mocking: jasmine has a nice mocking support that really helps
You really do not need to use Selenium for simple unit tests-- it complicates the configuration and is a more difficult programming model than a simple unit testing framework.
I've struggled with this a lot. I think Selenium is your best bet especially since it sounds like you've used it before. The other stuff for JS is mostly unit testing.
Not to diminish machineghost's answer, JS Test Driver rocks for unit testing.
I ended up using QUnit since I found it very simple to just insert the PUT (Page Under Test) in an <iframe>, and use jQuery to access it from the unit tests.
That way I don't need any other external dependencies other than the browser itself (the logic resides 100% in the client) and any text editor.
Turboframework uses javascript, jasmine, selenium and runs with node. You can literally create a test project and run web automated tests in less than 10 minutes. To avoid repeating the documentation that is already available, here's the link to a quick start guide:
https://turboframework.org/en/blog/2021-03-03/automate-your-web-application-tests-in-less-than-ten-minutes