I am trying to create a page object model in flutter for testing. Is it possible to create a test driver in one class(with setup and teardown) and use it in different page object classes and test cases?
Related
I am reading the chapter 11 page number 90 of clean architecture.
I agree with author that we should use interfaces instead of depending upon the volatile concrete classes to avoid the source code dependency on the concrete class to make our code more modular. He mentions the below pattern to handle the volatile dependency in the code.
In the above image author suggest to use the FactoryServiceImpl to create the instance of the ConcreteImpl.
What's the advantage we get in using the FactoryService? Anyway in the main method we will have to create the instance of FactoryServiceImpl and pass to the Application. Instead we can directly create the instance of the ConcreteImpl and pass it to the Application?
What's the advantage we get in using the FactoryService?
The application does not depend on FactoryServiceImpl nor ConcreteImpl. The advantage is that if you want to test the application class you can easily mock the FactoryService just by providing a test/mock implementation.
Since the application class does not depent on the concrete implentations, it is also not dependent on the dependencies of those classes. E.g. the FactoryServiceImpl might contain a dependency to an external service that it passes to the ConcreteImpl when it creates it - could also be a database. Maybe the FactoryServiceImpl uses a fancy framework that you don't want the application to "indirectly" depent upon.
Anyway in the main method we will have to create the instance of FactoryServiceImpl and pass to the Application. Instead we can directly create the instance of the ConcreteImpl and pass it to the Application?
Yes you could create a ConcreteImpl and pass it to the application, BUT Uncle Bob talks about volatile objects in chapter 11. This means that the application creates ConcreteImpl on the fly when it needs it. Maybe a ConcreteImpl is stateful and belongs to a user request. It might also be possible that the factory takes arguments that it uses to create a ConcreteImpl and this arguments change depending on the application state. Thus the application must create a new ConcreteImpl whenever the this state changes. Thus you can not create one instance in the "main" method.
I'm creating unit tests using PHPUnit in Laravel. Upon creating unit tests, I encounter that on some test I need to prepare database data such as selecting existing records, inserting new record and etc.
I separated each unit tests class based on my application functionality. So for example my application has user management module then I would have UserManagementTests class. Before starting to run the unit tests method inside this class I would like to prepare all database data needed so I won't need to query the database in each method for me to get the data needed for that specific unit test method.
I'm new to PHPUnit and I don't know what keyword should I search for this problem.
Other info:
My application uses multiple databases
Each database already have existing data and most of them should not be deleted during tests. So my option for some tests is to create new record, run the test, and delete the created record to preserve the original state of my database - I do this using the DatabaseTransactions trait of Laravel.
If you've got all the data you need in seeder classes, you can just call them as needed inside the test methods or the test class's setUp() method.
use Illuminate\Support\Facades\Artisan;
Artisan::call('db:seed', ['--class' => 'MySeederClass', '--database' => 'testingDatabase']);
I am using PHP Laravel framework and have a Controller class.
I have written a unit test for the class.
Is it also necessary to write integration test for the same class?
Or do Controller classes only need integration instead of unit tests?
How about for Repository classes that call Eloquent Models and also Adapters that call third party packages?
Should they only have integration tests, since they are not under my control?
Thanks
I created a solution where I develop a client library for Windows 8 phone (containing a bunch of utility and helper classes). Most classes in the library are not public and I don't want them to be exposed in the library. There are only a few classes which in turn use other classes that are not public.
I wanted to unit test each and every class I wrote and I created another project by right-clicking solution and then "Add->New Project->Windows Phone Unit Test App". The unit test app got created fine with:
using System;
using Microsoft.VisualStudio.TestPlatform.UnitTestFramework;
namespace MyClientLibraryTest
{
[TestClass]
public class UnitTest1
{
[TestMethod]
public void TestMethod1()
{
}
}
}
Now in the unit test app I wanted to refer to my client library and I added the client library DLL to the test project.
When I try to see something like:
MyClientLibrary.Foo where Foo is not a public class it is not visible in the test method TestMethod1().
I thought as the client library and the unit test project are in the same solution, they are visible.
As the non public classes in the client library are not visible and I am not sure if I am doing it the right way.
Need some guidance from .Net developers on this as I started coding .Net and Windows 8 phone very recently.
My question is not just related to Windows 8 phone client library.
Let's say I write a client library to be distributed, how do I unit test it?
How do I make sure that all classes are unit tested?
Am I doing the right way to create a unit test project or do I have to write the unit test within the client library itself and not outside in a new project?
Thanks for your time...
Have a good day!
I need to create some functionality that will be used by nearly all my controllers.
So I need to create a custom class. Now do I do this as a Core class? Or as a library? How do these differ?
I use the core class override technique when there's some behavior of one of the core classes that I want to change project wide. A great example of this is using Jamie Rumbelow's model class in /core/MY_Model.
For functionality that will be USED in each controller, I build a library to perform those functions and autoload it, then call the functions from that library as needed.
You want a library is you are developing a class. For simple functions, create a helper. If you are developing functionality that interacts with your database, create a model.
Add your custom helpers and libraries in you application folder.