We are using Backbone in our developed application (written by a colleague) and I was tasked to add unit testing framework to verify the correctness of our application for continuous integration. After starting to look at other things, I am trying out qUnit as it seems simple. To start, I thought of creating a simple Backbone model in qUnit, but is having trouble. Hope someone can enlighten me. Here goes:
For organization and clarity of code, we have a convention of naming our Backbone models with prefix of App.Models. For example, we have App.Models.Target which extends Backbone.Model in Target.js under App/Models/ folder.
In qUnit, I have:
test( "Target is valid, Target edit should return true", function() {
var model = new App.Models.Target();
console.log(JSON.stringify(model));
ok(true);
});
which fails but shows minimal if no helpful message.
So, I tried playing around and renamed App.Models.Target to simply Target, and replaced App.Models.Target in my qUnit test again as Target and everything worked perfectly. I am very convinced that the error is caused by the prefix, but removing these prefix seems backwards to me (testing framework should be able to handle these things if you can run the code anyway, right?).
I think, (and I hope) there is a way to do this without renaming our Backbone entities to remove our prefixes. I just can't see one from the internet yet. All the examples seem so trivial.
Can someone give a tip/recommendation to solve my problem? Any help will be greatly appreciated!
Related
I would like to start automating the testing of my app written in CodenameOne, but I find it difficult to visualize how to use the TestRecorder (section "Unit Testing") for "industrial" testing.
If anyone here is already using it, could you share a few tips about how you use it?
E.g. how do you use the different "Asserts" buttons, how do you structure your tests into suites and how do you chain them together (e.g. so each test case will start in the right context like where in the navigation structure it is supposed to run), do you need to manually edit the tests, ... And is there anything to be aware of before creating lots of tests interactively, e.g. to avoid that your tests are invalidated by some irrelevant change to your UI?
I read in the blog post from May 2017 that the TestRecorder "wasn’t picked up by many developers and as such it stagnated". I tried TestRecorder and immediately came across a seemingly basis error in it (missing test for null) when recording a test case using the Toolbar, which gave the impression it is still the case. So, if anyone here is using another approach that is working well for you, I'd love to hear about that.
See the test classes we use to test Codename One itself here: https://github.com/codenameone/CodenameOne/tree/master/tests/core
You can use the test recorder to generate a skeleton but you can do this manually just like any test. The test API lets you invoke the app or just pieces of it and perform assertions on the behaviors within.
Is there any way to auto-generate Swagger documentation (or similar) for a Nancy service?
I found Nancy.Swagger, but there's no information on how to use it and the demo application doesn't seem to demonstrate generating documentation (if it does, it's not obvious).
Any help would be appreciated. Thanks!
In my current project I've been looking a lot into this problem. I used both nancy.swagger and nancy.swagger.attributes.
I quickly discarded Nancy.swagger, because for me personally it doesn't sound right that you have to create a pure documentation class for each nancy module. The attributes solution was a bit "cleaner" - at least codebase and documentation were in one place. But very fast this became unmaintainable. Module code is unreadable because of many attributes. Nothing is generated automatically: you have to put path, all parameters, even http method as an attribute. This is a huge effort duplication. Problems came very fast, a few examples:
I changed POST to PUT in Nancy and forgot to update [Method] attribute.
I added a parameter but not the attribute for it.
I changed parameter from path to query and didn't update the attribute.
It's too easy to forget to update the attributes (let alone documentation module solution), which leads to discrepancies between your documentation and actual code base. Our UI team is in another country and they had some trouble using the APIs because docu just wasn't up-to-date.
My solution? Don't mix code and documentation. Generating docu from code (like Swashbuckle does) IS ok, but actually writing docu in code and try to dublicate the code in docu is NOT. It's not better than writing it in a Word document for your clients.
If you want Swagger docu, just do it the Swagger way.
- Spend some time with Swagger.Editor and really author your API in
YAML. It looks all-text and hard, but once you get used to it, it's
not.
- Spend some time with Swagger.Codegen and adapt it (it already does a fair job for generating Nancy server code and with a few
adjustments to moustache templates it was just what I needed).
- Automate your process: write a couple of batches to generate your modules and models from yaml and copy them to your repository.
Benefits? Quite a few:
-
Your YAML definition is now the single truth of your REST contract.
If somewhere something is defferent, it's wrong.
Nancy server code is auto-generated
Client code-bases are auto-generated (in our case it's android, ios and angular)
So whenever I change something in REST contract, all codebases are regenerated and added to projects in one batch. I just have to tell the teams something was updated. They don't have to look through some documents and search for it. They just have their code regenerated and probably see some compile errors, in case of breaking changes.
Do I still use nancy.swagger(.annotations)?
Yes, I do use it in another project, which has just one endpoint with a couple of methods. They don't change often. It's not worth the effort to set up everything, I have my swagger docu fast up and running. But if your project is big, API is changing, and you have multiple code-bases depending on your API, my advice is to invest some time into a real swagger setup.
I am quoting the author answer here from https://github.com/khellang/Nancy.Swagger/issues/59
The installation should be really simple, just pull down the NuGet package, add metadata modules to describe your routes, and hit /api-docs. That should get you the JSON. If you want to add swagger-ui as well, you have to add that manually right now.
No. Not in an automated. https://github.com/yahehe/Nancy.Swagger needs lots of manually created metadata.
There is a nice article here: http://www.c-sharpcorner.com/article/generating-api-document-in-nancy-using-swagger/
Looks like you still have to add swagger-ui separately.
I'm upgrading an application from angular 1.0.5 to 1.2.19 and I can't get my head around the following issue.
This fiddle demonstrates the old behaviour. Check the console output and compare it with the new angular version in this fiddle.
We are using coffee script so removing the return value is an option or even better
return this
at the end works. But this seems to be the wrong approach and I would like to understand why it's acting differently to find the best approach to rewrite stuff.
I'm not sure why that worked in the old version of Angular but generally speaking in JavaScript when you define a constructor you should either return undefined or this. I came across this post that talks about what can happen when you return something else: http://www.bennadel.com/blog/2522-providing-a-return-value-in-a-javascript-constructor.htm
If you're using coffeescript though you can just create a class for your service. Take a look at this article for more info on using a class as a service http://alxhill.com/blog/articles/angular-coffeescript/
I have been reading tons of articles on unit testing. I am specifically using angular.js right now and came to the conclusion that unit testing = great. I also understand what unit tests are conceptually, but I honestly have no idea what I am doing or looking for. I already started the angular application and before I continue, I feel like I should start testing units of it. I have started tutorials and everything tells me "how" to do it using jasmine (or the other ones). I have a node project set up that is running Karma and a folder that has some *.js files in it to do all the describing/testing. However, it feels like the "tests" I write in a js sit in that file and do nothing.
What am I looking for? How do I actually view the results of the tests? It is all there, but I have no idea where exactly I am supposed to start. Am I supposed to be able to view the test in the browser? Is it supposed to run and save to a log file? Is it actually supposed to be tied to my ACTUAL code, or is it just rewritten logic that is supposed to mimic my code for testing?
This may be a dumb question, but I have spent a long time trying to figure out what exactly to look for. I noticed in some tutorials people have had little windows that tell them if their tests are failing or not (webstorm I believe) while they are writing the tests.
Any guidance would be greatly appreciated!
Using TypeScript, AMD, "requirejs", "breeze" but not "angular", I just upgraded from Breeze 1.4.0 to 1.4.6. Now, when "breeze" is loaded, it also tries to load "angular" which fails with...
Module name "angular" has not been loaded yet for context: _.
Use require([]) http://requirejs.org/docs/errors.html#notloaded
The problem seems to result from Breeze executing the following line.
var ng = core.requireLib("angular");
What have I done wrong so this code is executed anyway? Why does Breeze think that Angular has to be loaded?
When replacing the above line with the following, anything works fine.
var ng = undefined;
I'm having trouble reproducing this.
True, due to a peculiarity in the Breeze code, Breeze will execute the following line even when angular is not present
var ng = core.requireLib("angular");
... and that will fail with
Module name "angular" has not been loaded yet for context
because it can't find a library called angular.js (I assume you don't have it)
But that failure occurs inside another function (__requireLibCore) within a try/catch
function __requireLibCore(libName) {
var lib;
try {
if (this.window) {
...
if (window.require) {
lib = window.require(libName);
}
if (lib) return lib;
}
} catch(e) {
}
return lib;
Are you seeing some other code path in which this error is thrown?
UPDATE 11 December 2013
Thanks, #mgs, for your email explaining how you saw the exception. I summarize for those who read this later.
Breeze started looking for AngularJS in v.1.4.6. To be perfectly clear, Breeze does not need angular; it just wants to know if angular is available. Breeze doesn’t need knockout, jQuery or Q either. But under varying circumstances it may look for these libraries and use them if it finds them.
AFAIK there is no other way in requireJS to detect if a module has been loaded then to call require("angular"). Unfortunately, require("angular") throws an exception when it can't find that module.
Breeze itself does not fail because that call is caught in a try/catch. Many (most?) devs will never see this exception.
But #mgs has attached a requirejs.onError event handler ... which I hasten to add is a good practice. Of course his handler will see the "angular not found" exception even though Breeze caught it and moved on. He writes:
That “requirejs.onError” function is called, when Breeze tries to load Angular. In the real program this causes an entry into the log, and alarm bells are ringing. It was this entry that made me ask the question on StackOverflow.
What to do? I don't think Breeze can do anything unless someone knows a way to detect a loaded module without triggering the requirejs.onError event. I think it is up to the developer to compensate.
I recommend teaching your handler to ignore Breeze's attempt to find angular. Don't sound the "alarm bell" for this particular failure.
Alternatively, you could define a dummy module, as #mgs, did so that require finds an "angular" module. I'm not fond of this approach because it fools Breeze into believing that Angular is available and Breeze might act on that misunderstanding in the future. It's harmless today but who knows about tomorrow.
In any event, the mystery has been explained and suitable workarounds are now known. Thanks, #mgs, for the opportunity to explore this subject.
UPDATE 12 December 2013
We just released Breeze v.1.4.7 which includes the change you recommended ... using require.defined to check first if a module is loaded. Works like a charm.
I took the occasion to re-write the Todo-Require sample such that everything is loaded in a single require script line:
<!-- Require + main. All scripts retrieved async by requireJS -->
<script data-main="Scripts/app/main" src="Scripts/require.js"></script>
The documentation explains how it all works.
Thanks for your question and feedback.
you can force angularjs to be loaded by adding the following typescript line:
/// <amd-dependency path="angular"/>
alternatively you can make breeze depend on angular in your requirejs config.
Update In case you are not using angularjs you can safely exclude this file from your project : https://github.com/IdeaBlade/Breeze/blob/master/Breeze.Client/Scripts/IBlade/b00_breeze.ajax.angular.js