[Proposal] Adding Unit tests

[cangelis]

First, thanks for this great cms.

Looks like the project doesn't contain unit tests. I'd like propose to implement unit tests because of well known reasons. Then we can use a continuous integration service (eg TravisCI) to make sure each pull request works properly and can be merged. After implementation of the features and the unit tests the project can be ready to be released.

If this proposal is accepted by the community, I'll be pleased to help to implement tests.

[ericlbarnes]

Yeah we should add these and I'm all for it. I think the php side should be pretty basic. It's all just basic crud operations for the most part.

The js/coffee needs some tests but I haven't gotten around to them. 😦

[alexw23]

👍

[metalmatze]

I would definitely help to write unit tests. I'm all about testing since laravel. :-D
I'd only need to know to structure all the tests.

[metalmatze]

Hey,

I just wanted to let you know about the work I've done so far on unit
testing.

Right know I'm figuring out how to test Cache, Config & Validator as
global static classes. Is kind of tricky without laravel's bootstrapping.
I've tried to create a global Config class which returns Mockery...
http://paste.laravel.com/1dbw

Anyway. Check out the changes I've made and let me know any answers or
criticism.

https://github.com/MetalMatze/wardrobecms-core/compare/testing;DbPostRepository

[cangelis]

Laravel's Facades can be mocked easily without any extra work. http://laravel.com/docs/testing#mocking-facades
+
I think injecting Eloquent classes as a dependency to the Repository classes is not necessary. We can assume that the Eloquent classes are working as expected because they were already tested in Laravel core. On the other hand, mocking Eloquent classes is not easy in some cases. That's why we're using Repository classes. I think we should test Repository classes using a real database (SQLite in memory ?) so we can see whether they work as expected or not.

[metalmatze]

Yes facades can be mocked easily, but not if we don't have a laravel instance. Since we don't have the bootstrap.php in the core. So we'll have to create some other workaround. That will only work in a default laravel app.

Well, we (I) wanted to create unit tests. They test each and every single method of the repository. They should test everything around eloquent. In order to be able to do that we need to mock eloquent and test if it get's the correct values.
For example in activeByTag() if eloquent get's 5 if $perPage is not an int.

What you proposed would be functional/integration tests, that should definitely be added in the future.

[cangelis]

Then first, we should create a bootstrap file to include autoloaded classes. Since this is a Laravel package, we should use these mocking features of Laravel.

You're right we should have unit tests of repository classes but I just find it too early. Everybody has different approach in testing. What I mean by saying apply functional tests on Repository classes is that I find unit testing the Repository classes is too much because they usually have single line of code, but I don't say what you do is wrong. In other words, I find unit testing the controller classes is more important than repository classes in this first step.

So I think we should decide how we will test this app in the first step as a community to prove the stability of the app. On the other hand, the leaders or the community should decide about some practices.