Is it possible to have a fixture change between test methods? If so, how can I do this?
My syntax for this problem :
In the cakephp framework i am building tests for a behavior that is configured by adding fields to the table. This is intended to work in the same way that adding the "created"
and "modified" fields will auto-populate these fields on save.
To test this I could create dozens of fixtures/model combos to test the different setups, but it would be a hundred times better, faster and easier to just have the fixture change "shape" between test methods.
If you are not familiar with the CakePHP framework, you can maybe still help me as it uses SimpleTest
Edit: rephrased question to be more general
I'm not familiar specifically with CakePHP, but this kind of thing seems to happen anywhere with fixtures.
There is no built in way in rails at least for this to happen, and I imagine not in cakePHP or anywhere else either because the whole idea of a fixture, is that it is fixed
There are 2 'decent' workarounds I'm aware of
Write a changefixture method, and just before you do your asserts/etc, run it with the parameters of what to change. It should go and update the database or whatever needs to be done.
Don't use fixtures at all, and use some kind of object factory or object generator to create your objects each time
This is not an answer to my quetion, but a solution to my issue example.
Instead of using multiple fixtures or changing the fixtures, I edit the Model::_schema arrays by removing the fields that I wanted to test without. This has the effect that the model acts as if the fields was not there, but I am unsure if this is a 100% test. I do not think it is for all cases, but it works for my example.
Related
In the notes of this commit, the Ember team have made it very clear that App.__container__.lookup() is not the way to get at controllers. Instead we should use the needs property.
I understand the rationale behind this, and the idiomatic way to access singleton controllers.
However, in my app, I have some cases where I need instance controllers. In that case, I am using App.__container__.lookupFactory() to get at the prototype which I can then create() or extend()
Is there a better way to do this (without using __container__?
Edit:
Here is an example use case.
App.MyContainerView = Ember.ContainerView.extend
...
addChildView: ->
#get("content").pushObject(App.MyChildView.create(...))
The above example will push a new view onto the stack (allowing views to be dynamically created)
However, these views will (may?) not have the right container (and other properties?) set due to being created using App.MyChildView.create(). This is especially true in cases where we are doing a partial integration of Ember into an existing app.
The way to create these views would instead be:
App.__container__.lookupFactory("view:my_child").create()
In which case everything would be ok.
Additional use cases exist, for creating instance controllers outside the context of the router.. but the idea is the same.
I don't know if you're still looking for an answer. I am also struggling with how to do things "the Ember way".
This answer put me on the right track, and should be relevant to your question:
"Please ensure this controller was instantiated with a container"
As for me, I had the same problem as in the above question: when I manually instantiated my App.AnyOtherController with App.AnyOtherController.create(...), then inside this controller, I could not access dependency injections (such as a session object that I make available to all my controllers and routes).
Instantiating the same controller this way solves the problem by giving the controller a container:
this.container.lookupFactory('controller:any_other').create(...)
You should be able to access this.container from any view, and I guess, any controller, as long as they have been given a container.
You can Ember.String.decamelize('AnyOther') to convert the CamelCase controller name to a suitable string.
More on containers here: http://ember.zone/beginning-to-understand-the-ember-js-container/
If it doesn't help you, I still hope this helps someone out there, as this container stuff is a bit tricky at first...
I am working in a Python project where I have some classes that extend from another that gives them an "ORM Layer" to call it in some way. These objects are persistent in the DB when their attributes change.
The big problem comes when I want to test the logics of these objects, it really gets close to impossible to mock everything and I'm going nuts.
Is there any strategy or directives to test this kind of situation? Thanks.
The generic strategy is not to test the database or other frameworks. Assume that they work.
I don't know which persistance / ORM framework is used. But a good strategy here is monkey patching: Instead of mocking the framework, you overwrite methods in your test that try to access the database with empty ones:
def nop(*args, **kw): pass
ORFramework.BaseObject.messThingsUp = nop
where messThingsUp is a method of the class BaseObject that you want to get rid of.
today I had a discussion with my colleguaes about how we should manage fixtures in our django application. We cound not find any solution that would satisfy everyone, so I'm asking this question here.
Suppose we have quite big django project with dozen of applications inside, each application has tests.py file with several TestClasses. Having this, how I should manage test data for all of these applications?
From my perpective, there is 2 different ways:
Store all data in separate for each application test_data.json file. This file will contain test data for all models defined in the application's models.py file, irrespective of where this data is used (it can be used in tests from different application)
Store some common data that would be probably required by all tests (like auth.users) in test_data.json and data for each TestCase in a separate test_case.json file.
From my perpective, second approach seems to be more cleaner, but I would like to know if somebody could tell me the concrete pros and cons of these approaches or may be suggest some other approach?
If you think about the cleanest way to define test data for your tests, I would like to recommend you read about django-any application:
django-any the explicit replacement for old-style, big and error-prone
implicit fixture files.
django-any allows to specify only fields important for test, and fill
rest by random with acceptable values.
It makes tests clean and easy to undestood, without reading fixture
files.
from django_any import any_model, WithTestDataSeed
class TestMyShop(TestCase):
def test_order_updates_user_account(self):
account = any_model(Account, amount=25, user__is_active=True)
order = any_model(Order, user=account.user, amount=10)
order.proceed()
account = Account.objects.get(pk=account.pk)
self.assertEquals(15, account.amount)
The same approach available for forms also (django_any.any_form)
This solution is helpful for avoiding to keep extra data in you DB while your tests are executing.
Let's say in my user model I have a ChangePassword method. Given an already initialised user model, it takes the new password as a parameter and does the database work to make the magic happen. The front end to this is a web form, where the user enters their current password and their desired new password. The controller then checks to see if the user's current password is correct. If so, it invokes the user model's ChangePassword method. If not, it displays an error to the user.
From what I hear you're supposed to unit test the smallest piece of code possible, but doing that in this case completely ignores the check to make sure the user entered the correct current password. So what should I do?
Should I:
A) Unit test only from the controller, effectively testing the model function too?
OR
B) Create 2 different tests; one for the controller and one for the model?
When in doubt, test both. If you only test the controller and the test fails, you don't know whether the issue is in the controller or the model. If you test both, then you know where the problem lies by looking at the model's test result - if it passes, the controller is at fault, if it fails, then the model is at fault.
A)
The test fails. You have a problem in either the model or the controller, or both and spend time searching through the model and controller.
B)
The model and controller tests fail... chances are you have a problem in the model.
Only the controller test fails... chances are better that the problem is not in the model, only in the controller.
Only the model test fails... hard to see this happening, but if it does somehow then you know the problem is in the model, not in the controller.
It's good to test both layers. It'll make finding the problem later that much easier.
There should be multiple tests here:
Verify the correct password was entered.
Validate the new password, e.g. doesn't match existing one, has minimum length, sufficient complexity, tests for errors thrown, etc.
Updating the database to the new password.
Don't forget that the tests can also help act as documentation of the code in a sense so that it becomes clear for what each part of the code is there.
You might want to consider another option: Mock objects. Using these, you can test the controller without the model, which can result in faster test execution and increased test robustness (if the model fails, you know that the controller still works). Now you have two proper unit tests (both testing only a single piece of code each), and you can still add an integration test if required.
Unit testing means to test every unit on its own, so in this case you would need to build two unit tests, one for the frontend and one for the backend.
To test the combination of both an integration test is needed, at least the ITSQB calls it like that.
If you code object oriented you usually build unit tests for every class as that is the smallest independent unit testable.
A) is not a unit test in my opinion since it uses more than one class (or layer). So you should really be unit-testing the model only.
I have an app built on Model-Glue: Unity that contains some search forms. I need to trim leading and trailing spaces from search strings before using them to query the database. I'm also keeping the search terms in a bean that a user can save and re-use.
My problem is that I am unsure where to perform that trim(). The bean seems to be the wrong place for it, as I'm keeping the bean simple (no logic). Normally I would take care of that when updating the bean, but I'm using MakeEventBean to keep things simple. Re-touching all of the data in the Service layer seems an unnecessary layer of overhead. And, lastly, doing it in the datalayer with the actual SQL query doesn't seem right either. It'll work, but the information in my search bean will still be wrong.
What have you done in such cases?
Disclaimer: I'm not a MG user, so I'm not sure if this will be good and possible approach. Just want to share the idea.
In case of Transfer ORM beans I do such specific things in decorators which extend auto-generated beans.
For example, I can easily override setter setSearchPhrase(phrase), where trim the argument value and invoke original method.
I ended up making my Beans a little smarter than they were. Rather than monkey with every single setThing() method, I added a trimAll() method simple applied a trim() to each of the private properties in the Bean.