Let's say I have a frontend application written in Angular and a backend application written in Django and Django Rest Framework. I created unit tests for backend application (with pytest) and I'm about to create some functional tests for the frontend application. The thing is that the frontend app needs access to the backend app in order to work correctly. I can write some mocks to handle that, but I am not sure if this is the best way to do that.
My question is, what is the best way to handle that? Should I use a single git repo for both applications or maybe a better way is to use two repositories, but then how to handle the tests for frontend application?
I was also thinking about using selenium with pytest, but then I would have to use a single repository. I am a little bit confused and would really use some good advice. Thanks!
Unit tests as the name suggests is testing separate units of the code in isolation. Meaning that it does not have to depend on any other part, else, you wouldn't know if the test is failing for that particular unit or the units it depends on.
As a result, all tests should mock the request to the backend and return valid responses (or invalid, if you're testing for error handling). The same applies to any other external service that the unit depends on.
Related
I have FastAPI project which does the following:
Register users(unauthenticated)
CRUD operations on user resources(authenticated)
What I want to do:
Develop an automated testing framework to unit test all the APIs
Run that on a devops platform like jenkins regularly
Run it locally before deployment
Some specific doubts I have:
For testing, should I use the OpenAPI generated client sdk or the FastAPI client or use the python requests module?
Authentication should happen only once and reuse the JWT token or fresh authentication for each API test ?
Should I use the same pydantic modules for dev and testing or re-write them to ensure that no issues were introduced in case of updated models ?
How to do proper unit testing when one API requires result from multiple other APIs?
Use the built-in TestClient
Use a fixture and let pytest sort it out for you; if it's too slow to reauthenticate each time, change the scope of the fixture to a larger scope (i.e. class, module, session, etc.). You can also use FastAPI's dependency_overrides to let your tests run with static authentication configured (so that you can skip actually authenticating in most of your tests).
You should test what you use in your application. Nothing specific written for your tests, except if necessary to make your application testable in a better way.
The only "proper" thing is that your API has been tested to work as you expect it to work. Do multiple API calls if necessary, but move them into fixtures to get composable sets of dependencies for tests (i.e. the result of the fixture can be cached and re-used for all tests in a test class if necessary). If you have tests that depend on a customer being created, create a fixture that creates a customer and use that fixture in the tests where a created customer is necessary.
for a front-end developer, who writes angular code, what part of a javascript front-end project should I be unit testing? I find it needless to test a lot of the code, and my biggest hang up is which part of the angular services needs to be tested? if $httpBackend is a mock call, what's the point of calling it?
As your project grows in complexity, you may find that your angular application is doing a lot. Angular's design allows the client to take a lot of the responsibility for processing and rendering data from the server.
Yes, I agree, you shouldn't test anything but your own code. So, writing tests for $http is useless. However, if you are expecting the server to return a specific JSON contract, and you want the assurance that you are mapping that correctly to a structure that you will use in your angular app, that is worth testing. Further, if you are making calculations in services or controllers, that logic is worth testing.
Angular itself is set up to support TDD because it has a nice separation of concerns between the view, controller and services (even directives can be compiled and tested). All of the javascript code that you write is a good candidate for test coverage. So, IMHO, you should be unit testing your directives, your controllers, and your services. You can get as detailed as you want to give yourself the assurance that your code is solid.
I have a fairly conventional Grails application. It's monolithic; although it's somewhat split into plugins along functionality lines, it is built into a single war for deployment. Due to company architectural constraints, I need to consider isolating the app's persistence into a web service (or series of web services). What's the best approach to dividing a Grails application into a persistence service and a presentation application?
Put your domain classes in a Grails plugin, and have two distinct Grails applications, one for your web front-end and one for your web service. Both access the database directly, but code for persistence is not duplicated.
Here is a blog post that have some more details on how to realize that.
I don't have an out-of-the-box solution for your problem, and I don't believe there is one. I'll just explain the solution I use and what I would consider in your case.
In my organisation, our approach is to separate our applications in a Grails back-end and a front-end in Flex. The reason is that we have many ready-to-use Flex components that would take too much time to re-implement using pure web technologies, but here's not my point.
Creating a REST back-end in Grails is quick, as views are scaffolded when appropriate, controllers are straightforward, and input validation is greatly simplified by Domain constraints.
The drawback of this split is that definition of domain objects have to be duplicated in the front-end. You might includes objects validation in the front-end or not, but if you omit them, it will have an influence on UI responsiveness (requests to the REST back-end in AJAX calls for real-time validation to get the errors). At the end, our application is quite cumbersome because modifying objects in the back-end implies modification in the front-end. Furthermore, we do validation in both the front-end AND the back-end, and this code is not shared, so it must stay in phase and maintained at two places.
Our applications are split in a way that's similar to two completely distinct Grails applications that would share no code. A solution that would work in your case but is not what you are looking for, for sure.
In your case, I see two viable solutions for the web front-end:
use the Groovy REST client library to fetch and send back your domain objects directly from your controller. If needed, pack them in command objects that reflect your domain objects, so that you can share validation code with the back-end.
create some kind of REST GORM that replaces Hibernate with queries to your REST web service. You could look at the GORM for Mongo Plugin as an example of how to create such a GORM replacement.
I like the last idea, it would be a useful public plug-in. It doesn't exist yet, unfortunetly.
I recently starting learning test driven development, namely MXUnit, and I love the idea's behind it. I can understand the idea of using TDD with stand alone CFC's, but when it comes to using it with OOP based Frameworks, primarily FW/1 and CFWheels, I am not sure how to use MXUnit with the framework CFC's (controllers in FW/1 and Models and Controllers in CFWheels).
Does anyone know where I can find some resources on using MXUnit with Frameworks?
I can only talk about F/W 1 here as I have not used CFWheels (some info here in another SO question), but in my opinion framework unit testing can be simplified by proper use of a service layer.
The idea is you test service layer objects using MXUnit and leave the framework controllers (for example in FW/1) very lightweight. Essentially the controllers are just passing parameters to the service layer, getting a response back and displaying a view.
The reasoning is that the framework is the least likely place you'll introduce errors - so concentrate your testing on the service object, i.e. the core business logic of your application.
Interestingly, in other non-ColdFusion frameworks (such as Grails) the framework is not tested, tests are created for your model ('domain classes' in grails that model the data) and your service objects, but the framework is assumed to work fine. The idea there - again - is to keep logic out of your controllers and test your service layer and domain model.
I hope that helps in some way.
My web app is a Google OpenID consumer (with Attribute Exchange and OAuth Extension) and I need to write some unit test for it [edit: to test the unit that is responsible to interact with google].
The problem is that default OpenID login procedure needs user interaction (entering user/pass) which is not possible in unit test.
Do you have any idea how can I solve this problem and unit test my OpenID consumer app?
(I prefer not to run my own OpenID provider.)
You need to use a remote controlled browser for this. Selenium was made for this use case.
(indeed they are called functional tests then).
Search on Google for the best way to integrate selenium tests into your web framework.
If I understand you want to test your all application and not just "unit test" it.
The actual test framework depends on the technology your application is using. For example there are many UI and web automation tools that can do what you want.
You should also unit test your core functionality or at least write several integration tests that work against an actual Openid provider but instead of running the entire application just test the functionality of the class (if you're using language that has classes) to make sure it can get the b.
I would also write a couple of unit tests that call a fake provider to test how your code behaves in case of error, connection problems and plain vanilla responses.