My boss says we should use a unit test. I have to test the functionality of a calendar module with click functions, is it possible to make a module visible in a unit test so I can run click() methods on it to test features or are unit tests always invisible in Ember?
I've tried making a unit test with similar syntax to an integration test but it doesn't work. I need to see the module to run click methods on it to test basic functionality, is this possible?
module('Unit | Mixin | eg picker/calendar single')
test('it works', function (assert) {
let EgPickerCalendarSingleObject =
EmberObject.extend(EgPickerCalendarSingle);
let subject = EgPickerCalendarSingleObject.create();
assert.ok(subject);
});
The vocabulary around testing is different for different languages and frameworks. I would consider Ember's integration tests to be the same as what a PHP developer would call a behavioral unit test whereas what a Java developer calls and integration test isn't even part of the Ember ecosystem.
Your boss isn't wrong, unit tests are usually the best way to test small isolated interactions, we just call them integration tests in Ember.
Source: been doing TDD for a long time across many languages, jobs, and frameworks.
Related
Recently,I am studying about django test. Because I need to build unittest and integration test in my website.But I find that the tutorial of integration test in django is really less and it often occurs when I hit a link named "integration test" ,I only see the title "functional tests".So,are they the same? if not,how can I start a integrstion test in django?
You cannot compare these notions.
The opposite to integration testing is unit testing. Unit testing - is testing different isolated parts (usually small code blocks) of your system separately - it's very focused, integration testing is testing how these different parts of your system work together - for example, url routing, logic in views, logging, querying your models etc.
Functional testing is a type of black box testing that usually checks that some (usually documented) piece of functionality works as expected.
You may have all sorts of tests in your django project:
unit tests of different library, helper functions
view tests (this could be already called integration tests, because it may include dealing with models, logging etc)
ui tests (high-level tests, that could be called functional/integration/system)
..
If you don't have tests at all, I'd start with high-level tests. For example, I'd take selenium and django_selenium and write some in-browser tests that will go through pre-defined scenarios, like login->do smth->logoff, login with incorrect credentials->see error etc - and these tests would be called functional and system and integration and ui and etc - you got it I think.
See also:
Testing Django Applications
A Guide to Testing in Django
Carl Mayer's "Testing and Django" slides
Integration Testing in Python
Hope that helps.
I am starting in node.js unit testing, and I have been investigating which was the most used framework for unit tests in node.js. I'd like to start with the most used framework just to makes things easier as there might be more information about it. According to many sites that could be Mocha.
While I understand this module for doing integration tests I don't really know how to work with it by using feautures like stubbing dependencies. I have seen mocha doesn't provide mock/stub functionalities, so I don't really know how people usually deal with these problems.
So I'd like to know what modules are the most popular nowadays for doing unit tests, stubbing dependencies... A short example would be great.
Thanks
The current suite of modules combined together in many node.js projects seems to be:
Mocha for the actual test harness itself
Chai for assertions
Sinon for mocking/stubbing
All of these work both in node.js as well as the browser, which is important to many people including myself. There are many choices available as you might expect, although when it comes to mocking and stubbing I believe Sinon is clearly the current popular choice.
Here's a small example in coffeescript that uses all of these libraries. It tests that when you fill in the sign in form and submit it, your info is passed to the API properly.
describe "UserSignInView.signIn", ->
it "should submit the user credentials", ->
sinon.spy _OT.api, "sendJSON"
testUser =
email: "test.user#othenticate.com"
password: "password"
$("#OT_signInForm .OT_email").val(testUser.email).change()
$("#OT_signInForm .OT_password").val(testUser.password).change()
$("#OT_signInForm .OT_signInButton").click()
assert.ok _OT.api.sendJSON.called
credentials = _OT.api.sendJSON.lastCall.args[0]
assert.equal credentials.email, testUser.email
assert.equal credentials.password, testUser.password
options = _OT.api.sendJSON.lastCall.args[1]
assert.equal options.url, "/othen/users/authenticate"
assert.isDefined options.error
assert.isDefined options.success
I am new to testing in general and am working on a Grails application.
I want to write a test that says "when this action is called, the correct view is returned". I don't know how to go about deciding if I should make something like this a unit test or an integration test. Either test would show me what I want - how do I decide?
One problem with integration tests is their speed. For me, integration tests take 15+ seconds to start up. In that time, certain things do slip out of mind focus.
I prefer to go with unit tests that start in no more then 2 sec and can be run several times in those 15 seconds. Especially with mockDomain(). Especially with Grails 2.0 implementing criteria and named queries in unit tests.
One more argument for unit tests is they force you to decouple your code. Integration tests always tempt you to just rely on some other component existing and initialized.
From Grails Docs section 9.1
Unit testing are tests at the "unit" level. In other words you are
testing individual methods or blocks of code without considering for
surrounding infrastructure. In Grails you need to be particularity
aware of the difference between unit and integration tests because in
unit tests Grails does not inject any of the dynamic methods present
during integration tests and at runtime.
From Grails Docs section 9.2
Integration tests differ from unit tests in that you have full access
to the Grails environment within the test. Grails will use an
in-memory HSQLDB database for integration tests and clear out all the
data from the database in between each test.
What this means is that a unit test is completely isolated from the Grails environment whereas an integration test is not. According to Scott Davis, author of this article, it is acceptable to write only integration tests...
Unit vs. integration tests
As I mentioned earlier, Grails supports two basic types of tests: unit
and integration. There's no syntactical difference between the two —
both are written as a GroovyTestCase using the same assertions. The
difference is the semantics. A unit test is meant to test the class in
isolation, whereas the integration test allows you to test the class
in a full, running environment.
Quite frankly, if you want to write all of your Grails tests as
integration tests, that's just fine with me. All of the Grails
create-* commands generate corresponding integration tests, so most
folks simply use what is already there. As you'll see in just a
moment, most of the things you want to test require the full
environment to be up and running anyway, so integration tests are a
pretty good default. If you have noncore Grails classes that you'd
like to test, unit tests are perfectly fine.
First go through this chapter of the grails guide http://grails.org/doc/latest/guide/9.%20Testing.html
It talks about testing controllers and ability to get controller response like so :
controller.response.contentAsString
Now deciding on which test is more of an art rather than science. I prefer unit tests cause they are faster to run :)
Its a really interesting and challenging question to answer, but the truth is it really depends on what exactly you are testing.
Take the following test: "saving a book to the database". The hints are in the description. We are saying we need a book and we need a database, so in this case a unit test wont do because we need the integrated database.
My advice is write the full test description down and break it down like I did above. It will give you the hints to help you decide.
This is made easier with spock where you can use strings for test names.
I have been doing a lot a reading about unit testing.
Unit testing seems all well and good.
But it seems to miss a lot of the fundamentals of how the web works. User Interaction.
I have not seen any way a unit test could test for unexpected input, or test to make sure that an ajax call works etc.
Am I missing something here or is unit testing not really designed well for web development?
You are not missing anything.
Ideally unit testing is about testing a small piece of code, e.g. a class in isolation. For this you may want to use a unit testing tools such as JUnit or NUnit. Some people refer to this type of tests as developer tests.
In contrast to that you may want to test web applications as a whole. Some call this acceptance testing. For the latter you could use a tool such as Selenium. Tools like Selenium can test Ajax and other JavaScript as well.
You have even more options if you take a look at a tool like WebDriver as you will find that you can implement Selenium-based tests using a unit testing tool.
Take a look at Selenium.
I'm fairly new to unit testing. I have a site built in the 3-tier architecture, UI -> BLL -> DAL. And I used the asp.net Provider Model, so by making changes to web.config I can switch to DAL dll to target different data sources, to be complete the DAL is written with Entity Framework.
Now, my question is how do I unit test my BLL? I use NUnit.
If run/debug my site, the asp.net/IIS loads everything and gets the correct configuration from web.config, so things work, that is because the entry point is from IIS. Now if I use NUnit gui to test and say I have my test project "MySite.Test.dll" which have test cases to my BLL, how does the testing framework get the correct configuration to successfully run all the test. It needs the info in web.config to load the correct provider!
Now, in my DAL there is a App.config created there by EntityFramework, and in it there is just the connectionString. Should I put all the provider related configuration in this app.config? Or am I missing some big picture on how to correctly do this?
This should be a common thing I imagine people need to do constantly. Could someone give some detail on how do I unit test my lib.
Thank you,
Ray.
Edit: After reading the first 2 answers I think I should correct my description with integration testing. Basically instead of IIS as the entry point, use GUI tools like the NUnit to run and test my code through, so NUnit -> BLL -> DAL. How do people actually set it up?
Thanks,
Ray.
Looks like what you are trying to do - is integration testing...
Unit testing, by definition, testing Plain Old .Net Classes in isolation. No database, no configuration...so...as I see it, to do proper unit testing, you need to refactor your BLL to service layer and domain logic classes which you will test separately. Like: Service layer uses domain logic classes, and your unit test uses them. So, domain classes do not go to database, and you do not need connection strings and everything.
However, if you want to do proper integration testing with database, you might want to do that too. If this is what you need - google it, it's not difficult to get some configuration strings in nunit.config or something...I don't know the details.
However, I feel what you want to do is unit testing and not integration testing..
Ask yourself, WHAT EXACTLY DO I WANT TO TEST?
Unit testing does not test "everything". Refactor, invert dependencies, and try to test you business logic in isolation.
Instead of a "web.config" file in your unit test project, you'll need a "MySite.Test.dll.config" file instead where you can enter the correct configuration for the testing. Note, using this method you could use a different provider to connect to an in-memory database instead if you wanted.
You have a couple of different options depending on how isolated you want to be from the DAL. If you want to involve the DAL in your tests, then you can copy the connection string section of the app.config file to an app.config file in your unit test project. As #badbadboy says, though, this really is integration testing, not unit testing.
If you want to do proper unit testing you probably want to use dependency injection and interfaces to allow you to mock out the DAL from your BLL. I use LINQ-to-SQL so what I do is create an interface and wrapper class around the DataContext. This allows me to create a mock database to use for unit testing to test my entity classes in isolation.
Testing your entity classes in isolation will make your tests less brittle and allow you to set up the data for each test independently. This makes it much easier to maintain.
You also might want to look into a mocking framework that will make it almost trivial to generate the mock objects. I've had pretty good success with Rhino Mocks, but there are others.