When unit testing in magento, shoul I be using mocks for config tests?
I now there is the ecomdev module etc out there so please no answers directing me to this :)
I'm simply wondering whether any unit tests against the config for my modules should config object be mocked?
Unit testing in magento is hard. And to be honest not really possible at the moment (it will hopefully be completely different with magento 2). So if you ask me: No. don't test against mock objects, too much work, nearly no effect.
Test against the real config.
Related
How do you write unit tests for Htmx?
Stack overflow isn't letting me post such a short question, so this paragraph says that I didn't see docs or a library about this.
EDIT: Specifically, I wish to unit test in Django.
There are a couple of solutions to this:
Many server side platforms offer the equivalent of rails "functional" controller tests, and those can be used to test your partial end points, depending on what platform you are using.
You can write client side javascript tests in the normal manner. The htmx test suite uses chai.js & mocha.js to create a test suite, and sinon.js to mock out the server side. If you can run the tests against your actual server, that will simplify things even more.
Broadly, for day to day unit tests, I would lean towards the first approach because it will be more stable and "functional" and then use the second approach for integration testing.
I guess you use some kind of framework. For example Django, Laravel, Ruby on Rails, ...
Just use the tools of your framework to test your http endpoints.
For e2e tests I would use Playwright. But keep in mind this rule: 80% unittests, 15% integration tests, 5% e2e tests.
I have one e2e test which checks to happy path.
And a lot of pytest-django based tests.
For forms I use this pattern: html_form_to_dict
Maybe this question gets better answers in the discord channel, since there is no clear answer.
Q1: When is it ideal to run unit test? Should it be ran before each time I go to debug the app? Should they be ran before I commit changes to svn? I think if an app only has a couple of unit test it should be ran each time the app is about to debug. But lets say we hundreds of unit test that can take a bit of time to complete, not sure if this is ideal or not. I think then it would be better to just run them before committing or deploying.
Q2: In my app Im using a repository pattern with a service layer. I've done some research on how to test a service when the service is calling a repository and the repository is querying db. So in order for it to be a true unit test and not an integration test, I have to find a way to test without touching the database. I found people are using Moq to mock their repository. Here's where I have a problem, to me it seems if I mock a repository then I'm changing the behavior of how the method is suppose to work and to me seems like a pointless unit test. It doesn't seem you are actually testing your code. Am I completley wrong about this? Thanks for any advice.
Let me take a shot.
A1: When you refactor existing code, you should execute the corresponding unit tests (not all) and see if anything is broken by your changes. For new functionality you should implement new unit tests in parallel using TDD. You should never execute all the unit tests by your own but should use or rely on continuous integration.
A2: I had a same opinion like you. But now, I am convinced that unit testing for service layer is required. Whatever that can be covered using unit testing should be covered. At this point, the core of your services might just be a delegation to repositories but services evolves. The services takes up the responsibility of parameter validation, authorization, logging, transactions, batch-support API etc. Then, it is not only data-access but many more things. If I were in your place, I would go for unit testing of services by mocking repositories. Sometimes, services provide convenient methods on top of the repository.
Hope it might be of some help to you.
A1. When making changes to your code the more often you run the unit tests the faster you will get feedback on whether the behavior they were written to assert has been affected, so the more often the better! Unit tests should be very fast and running several hundred should only take a couple of minutes at most, but it might be worth looking into infinitest (if working with java, i expect an alternative will exist for .net etc) it is a plugin to eclipse and automatically runs your unit tests when eclipse builds your project. It is clever enough to run only the tests that have been affected since the last time it ran, e.g. if you update a test, or if you update some "application" code that is covered by some unit tests the specific tests will be executed.
A2. Unit tests will cover many different scenarios that will call your services + daos many times, using "real" services will make it difficult to guarantee the results of each call (and setting up the data for each test can be painful), but also the results can be slow. It's usually better when unit testing to mock these services and testing them independently with integration tests.
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.
We are starting to build infrastructure components in JSF2.0.
What is the best approach for unit testing them?
I tried JSFUnit in the past but wasn't satisfied with it. Is there an easier way to implement it?
This may be more integration testing than unit testing, but if you want to see how your components work in an actual browser, the selenium project has some nice features, and you can do it all through unit tests. You can look it over here: http://seleniumhq.org/docs/03_webdriver.html. I've found that between regular unit tests, unit tests using jmockit or the like, and selenium, I can cover pretty much everything when testing my components.
Cheers,
Bill
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.