I am new to the factoryboy package i want to use this for unit testing of my django app, previously i used factory package,
i want to know the exact difference between this 2 package becuase syntax and structure is almost same in both package
Related
I need to find out how I can instruct Vite to replace references to local/relative modules at runtime. The use case here is the test runner mocha-vite-puppeteer, which uses Vite to run tests, but then stubbing of modules of course does not work when using Node machinery such as proxyquire or rewire.
So I basically need to either be tipped of some existing software that can help me in doing this, or some tips on how to create my own "vite-proxyquire" using import.meta and friends.
A normal use for temporarily stubbing out ./my-ugly-module might be that you want to avoid loading some sub-dependency that has some ugly transitive dependencies that suck the entire application tree into your little test, or you want to avoid loading a sub-dependency that has some ugly side effects on the global state.
Existing solutions
Modern Web, a refreshing "bundler- and frameworkless" approach to web development using standard tools, talk a bit about the issue around how the immutable nature of ES Modules prevent usual stubbing patterns. They present a solution in the form of Import Maps, which essentially would be similar to the alias config in Vite (Rollup really), mapping a path to a module to some other file. The problem with a static solution like this is that it would replace all imports of a given module, not just for a single test. Modern Web has a solution to this where they have chosen to use a custom html page for each such test. To make this less of a hassle with regards to running, they then have a custom test runner that handles dealing with all these extra test html files. Doing something like that could be one way of fixing it, but it would require developing quite a bit of middleware/plugin code IMHO to make it work transparently with Vite. Without any advanced tooling it would also introduce a lot of extra files that seems a bit of a downside compared to todays imperative mocking of dependencies with proxyquire, Jest or Test Double from inside of the test files.
I have an architectural problem.
My team have large Django DRF application (lets name it "portal-backend") combined of set of apps, not installed as a modules but created manually. The apps are: blogs, news, entries, adminapi, gallery, comments, events, ideas, microposts, reactions, moderation, profile, and so on (about 50 apps).
Now I need to make some kind of "inheritance", use this product as a "base" in other team, and allow them to make changes in their nested classes.
For example if they need to change class blogs.views.BlogViewSet, they can just inherit it by they own class.
The "base" application must be installed with pip (if possible) or pulled from git (it's a single repo)
So, the main portal-backend shouldnt be changed in other team, just used as a base and extended by inheritance
Ideally my existing application should became some kind of high-level framework to create other portal-backends on the base of it with required modifications and additions on top of it.
What variants I thought about:
Split whole application into app-modules, put it into separate git repos, and install each app as a pip module. This method requires lots of work and has a problem that all apps are linked to each other so all modules need to be installed or nothing would work
Create some kind of building system, where "base" application git-cloned to specific folder (maybe as a git-submodule) and working app (that developed my other team) imports all the modules from this folder, or patches PYTHONPATH somehow to make imports transparent. Then, it would be possible to import mentioned class BlogViewSet and inherit from it. This looks like some duct-tape-solution, and quite fragile in wolowing development.
What would be your advice?
When I code in Ruby on Rails, I rely on Guard to listen for changes to the code base so when I'm writing tests, I don't need to manually run the tests in the file I'm working on each time.
https://github.com/guard/guard-rspec
What is the closest thing to thing for django so I can enjoy the same workflow?
Specifically, what I want to do is be able to have tests run, based on:
what run tests based on files I have changed, and not
know whether to run the test command based on whether a test run is currently taking place
work with existing tests written with unittest
work with something like factory boy to let me use factories instead of fixtures
I've used nose before, and pytest and I'm comfortable using both - but I haven't used many of pytests extensive set of libraries.
What are my options for this?
As written in a fairly old book XUnit Patterns NUnit 2.0 did not create new test fixtures for each test, and because of that if tests were manipulating some state of fixture it became shared and could cause various bad side effects.
Is this still the same? I tried to find it on official site but failed, and havent used NUnit for a while.
The fixture is created once for all of the tests in that fixture.
For a given fixture class, a FixtureSetup method is run once for all of the tests in a fixture, and a Setup method is run once for each test. So, any state that needs to be reset should be done in a Setup method (or TearDown, which is run at the end of each test.)
Since 3.13 you can configure that with
LifeCycle.SingleInstance A single instance is created and shared for all test cases
LifeCycle.InstancePerTestCase A new instance is created for each test case
https://docs.nunit.org/articles/nunit/writing-tests/attributes/fixturelifecycle.html
I found that this was an issue that affected me and also found this link which provides a bit of history to the issue;
https://blogs.msdn.microsoft.com/jamesnewkirk/2004/12/04/why-variables-in-nunit-testfixture-classes-should-be-static
I think one of the biggest screw-ups that was made when we wrote NUnit V2.0 was to not create a new instance of the test fixture class for each contained test method.
Not yet tested this in V3 to see if its changed
I am writing a repository. Fetching objects is done through a DAO. Creating and updating objects is done through a Request object, which is given to a RequestHandler object (a la Command pattern). I didn't write the DAO, Request, or RequestHandler, so I can't modify them.
I'm trying to write a test for this repository. I have mocked out both the DAO and RequestHandler. My goal is to have the mocked RequestHandler simply add the new or updated object to the mocked DAO. This will create the illusion that I'm talking to the DB. This way, I don't have to mock the repository for all the classes that call this repository.
The problem is that the Request object is this gob of string blobs and various alphanumeric codes. I'm pretty sure XML is involved too. It's sort of a mess. Another developer is writing the code to create the Request object based on the objects being stored. And since RequestHandler takes in Requests and not the object I'm storing, it can't update the mocked DAO.
So the question is: do I mock the Request too, or should I wait until the other guy, who is kind of slow, to finish his code before I write the test? Or screw it and mock out the entire repository when testing the classes that call the repository?
BTW, I say "mock" not in the NMock sense, but rather like faking the DB with an in-memory collection.
To test the repository I would suggest that you use test doubles for all of the lower layer objects.
To test the classes that depend on the repository I would suggest that you use test doubles for the repository.
In both cases I mean test doubles created by some mocking library (fakes where that works for the test, stubs where you need to return something to the object under test and mocks if you really have to).
If you are creating an implementation of the DAO using in-memory collections to functionally replace the database in a demo or test system that is different to unit testing the upper layers. I have done something similar so that I can give prototypes to people and concentrate on business objects not the physical model. That isn't for unit testing though.
You may of may not be creating a web application, but you can have a look at the NerdDinner application which uses Repository. It is a free PDF that explains how to create an application using ASP.NET MVC and can be found here: Professional ASP.NET MVC 2.0