-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix typo in README.md #6
base: master
Are you sure you want to change the base?
Conversation
@jamesrichford, I'm just learning JS/TS and web development and wanted to use browser test runner. It seems karma is popular and I saw this project but it seems it's a place holder. Do you have another test runner you use or any suggestions how to use automated testing using Alsatian in a browser? |
@winksaville you are correct this doesn't yet test in the browser but we are working towards it. It does work with other testing tools that test web browsers though e.g. selenium for end to end tests. For unit tests however I find it's better to run them in node as it eliminates the reliance on bad patterns like using globals. You should be even able to test rendering on node! Let me know which framework or frameworks you're looking to learn and I can share with you some examples :) |
For learning I created a nop-ts module written in TS and it's running under node, but now I want to test it on the browser. The biggest problem I've had is just getting the pieces working and I want to be sure I run tests in there actual environment. For instance, I had nop() running just fine when the 'app' was a TS app. But had a hell of a time getting it working in a JS app. Of course, this is mainly because of my ignorance, but I am trying to reduce it. Soooo, I really want to be able to test in a browser and karma looks like the tool of choice, but I'm all ears if you have a good/better suggestion. Longer term I'm looking at creating a "Single Page App" that uses WebSockets for client/server communication, Mithril for client side UI some crypto libraries on the client and server and finally the server talking to a Ethereum DAPP. And for good measure I hope to throw in some WebAssembly. I'd like this to be as isomorphic as possible so testing in situ I see as important. If Alsatian isn't ready yet, I'll probably give Jasmine a try, what you think I should do? |
I would say that when you're testing code there are two scenarios you are testing does the code I've written work? and does my application work does my code work?Generally what you want here is to prove new code I write is working and that it hasn't unexpectedly changed other code I.e. created a regression issue. In this scenario your focus is writing the code so things that you are interested in are:
For point one we want to adhere to good coding practices such as SOLID so we want to avoid things like the use of globals because of the instability of code that relies on them but also it's not very testable. Which brings us on to processes like TDD where we prove our code is of good quality by writing tests before code to ensure that the code does what we want it to - no more and no less. None of this requires the browser environment and in fact the browser environment can hinder you to some degree. Also most modern UI Frameworks will use concepts such as Virtual DOM so that it's not even necessary to have the browser environment. As for the second point if you're writing loads of tests in a TDD manor, speed is often a big concern of companies and developers alike. In practice tests will always make things quicker in the long run sure to eliminating bugs and generally getting to a stable solution quicker and avoiding regressions. Despite this it couldn't hurt to make life easier for ourselves when writing tests so by running your tests on node they are quicker as you don't have to wait for things like karma and a browser to load but also it's less points of failure as you've got less dependencies therefore less likely to have those frustrating blocking issues whilst developing. does my application work?To answer this question we need to use our application as the user would. If it's a web app then we need to run it in the browser, so karma right? Well karma is great at running unit tests but when we want to perform user actions like clicking a button or checking what colour something is or if it's visible not so much. This is where selenium comes in (there's a mini tutorial on the wiki). Selenium will run tests from the user's perspective and this will satisfy our goal. The tests themselves run on the server (so no need for karma) then selenium drives these through to the browser directly to perform actions or make assertions. In conclusion, karma shouldn't really be necessary but it's a nice to have and important for legacy solutions do that's why I've chosen to support it but you shouldn't need it going forward. We should have support soon though :) also on another aside if you want to use dom on the server side for testing purposes then you're in luck because there's a great package called js-dom which gives you this ability :) |
TYVM, I'll checkout Selenium and js-DOM. But I think having a Karma would
be a good idea.
…On Fri, Mar 3, 2017, 3:57 PM James Richford ***@***.***> wrote:
I would say that when you're testing code there are two scenarios you are
testing *does the code I've written work?* and *does my application work*
does my code work?
Generally what you want here is to prove new code I write is working and
that it hasn't unexpectedly changed other code I.e. created a regression
issue.
In this scenario your focus is writing the code so things that you are
interested in are:
1. What makes me write good code
2. What makes me a faster coder
For point one we want to adhere to good coding practices such as SOLID so
we want to avoid things like the use of globals because of the instability
of code that relies on them but also it's not very testable. Which brings
us on to processes like TDD where we prove our code is of good quality by
writing tests *before* code to ensure that the code does what we want it
to - no more and no less. None of this requires the browser environment and
in fact the browser environment can hinder you to some degree. Also most
modern UI Frameworks will use concepts such as Virtual DOM so that it's not
even necessary to have the browser environment.
As for the second point if you're writing loads of tests in a TDD manor,
speed is often a big concern of companies and developers alike. In practice
tests will always make things quicker in the long run sure to eliminating
bugs and generally getting to a stable solution quicker and avoiding
regressions. Despite this it couldn't hurt to make life easier for
ourselves when writing tests so by running your tests on node they are
quicker as you don't have to wait for things like karma and a browser to
load but also it's less points of failure as you've got less dependencies
therefore less likely to have those frustrating blocking issues whilst
developing.
does my application work?
To answer this question we need to use our application as the user would.
If it's a web app then we need to run it in the browser, so karma right?
Well karma is great at running unit tests but when we want to perform user
actions like clicking a button or checking what colour something is or if
it's visible not so much. This is where selenium comes in (there's a mini
tutorial on the wiki). Selenium will run tests from the user's perspective
and this will satisfy our goal. The tests themselves run on the server (so
no need for karma) then selenium drives these through to the browser
directly to perform actions or make assertions.
In conclusion, karma shouldn't really be necessary but it's a nice to have
and important for legacy solutions do that's why I've chosen to support it
but you shouldn't need it going forward. We should have support soon though
:) also on another aside if you want to use dom on the server side for
testing purposes then you're in luck because there's a great package called
js-dom which gives you this ability :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA-hHAX3d2HlRAzTAflnx4q6ofyvgoDcks5riKjRgaJpZM4MSf9H>
.
|
No description provided.