Thanks for answer...
I will try web2py.test in the comming days and report experience here...
Thanks to share this...
Richard
On Mon, Jun 3, 2013 at 12:19 PM, Vinicius Assef wrote:
> Hi Richard.
>
> I don't know how to create an in-memory db with postgres, but if you
> don't use any direct SQ
Hi Richard.
I don't know how to create an in-memory db with postgres, but if you
don't use any direct SQL command, you shouldn't have problems using
SQLite to test purposes.
No web2py.test doesn't manage any db replication. It just supply a
web2py environment usable to your tests. You should mana
Sorry to revive this old thread that get pretty long... But this one si for
Vinicius...
I have some time to explore and test web2py.test you publish...
The only thing, I would know for now is how to use in memory if I use
postgres in my app... Should I mock database with SQLite in memory as
sugge
Arnon, it is more than a little frustrating having a discussion with you,
as it appears you don't really pay much attention to what others are
saying. If you go back, you will see I have already addressed your
argument. You are correct that we make different assumptions, but the
differences are
I think that we fail to communicate because we have different un-spoken
assumptions. Let's take the following sentence as an example for what I
mean by that:
" less expert users should work on the easy tasks (that they can do), even
if it takes them a bit longer, leaving the more expert users to wo
> However, it seems that our common interest for a road-map, may not fit the
> way you operate - as you said, if developers don't need a feature, it will
> not be written.
> This nulls the possibility of web2py developers answering the needs of
> web2py users.
>
Arnon, I think you are somewha
Arnon, once again, we agree. It is true that *some* announcements are under
140 characters and that *all* announcements could be made by including a
link to a longer announcement. But then you need a separate place for the
linked longer announcements (such as Google Groups). Note, this very thre
Thanks for explaining, Massimo.
However, it seems that our common interest for a road-map, may not fit the
way you operate - as you said, if developers don't need a feature, it will
not be written.
This nulls the possibility of web2py developers answering the needs of
web2py users.
I agree tha
>
>
> Only for announcements that include links to the real announcement.
>
>
Let's see:
2.4.7 is out: http://web2py.com/init/default/changelog
(54 characters)
2.4.7 is out:
pypy support, thanks Niphlod
more bug fixes
(57 characters)
Obviously, for more verbose change-logs, a link can be
Hello Arnon,
let me explain how we operate. First of all we all volunteers so we try not
to commit to promises we cannot maintain. For the same reason we do not
feel like putting pressure on those volunteers.
web2py evolves more like natural evolution than by intelligent design. If a
feature i
On Saturday, May 25, 2013 4:25:39 PM UTC-4, Arnon Marcus wrote:
> I think that 140 charcters is more than sufficient for announcements.
Only for announcements that include links to the real announcement.
> I also think that one may be able to demostrate that the tweeter-community
> at large
>
> Ok, I get it now. But still, the most efficient way would be that the
> people with the most experience in a given area, would be the ones to
> maintain it. You are putting a restriction on scgedule that does not apply
> here. Within a time-frame that is smaller than what an experienced per
I think that 140 charcters is more than sufficient for announcements. I also
think that one may be able to demostrate that the tweeter-community at large
would agree with this assertion.
--
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To
Ok, I get it now. But still, the most efficient way would be that the people
with the most experience in a given area, would be the ones to maintain it. You
are putting a restriction on scedule that does not apply here. Within a
time-frame that is smaller than what an experienced person has avai
> Perhaps, but if they're not interested (or can contribute more value to
>> the framework in some other way), that may just leave you. If you're not
>> interested, why should anyone else be?
>>
>> Because other people are different than me. :)
> They might like this sort of thing.
>
That's my
> Not sure what you mean about duplication. If you have something to
>> announce, post about it here.
>>
>>
> That's even worse...
> Now you are suggesting a 3'rd avenue...
> What I mean by "duplication", is that you have multiple places that need
> to get updated every time an announcement is
> I think you would need a formal process to determine which items will make
> it into which releases.
>
How about a poll-voting thing?
>
> Not sure what you mean about duplication. If you have something to
> announce, post about it here.
>
>
That's even worse...
Now you are suggesting a 3'rd
> Perhaps, but if they're not interested (or can contribute more value to
> the framework in some other way), that may just leave you. If you're not
> interested, why should anyone else be?
>
> Because other people are different than me. :)
They might like this sort of thing.
> For further r
>
> Well, the way I understand it, the admin-app is a web2py app, and so is
> the examples-app - which is the we2py website, so assuming the admin-app
> uses a component for that tweeter-feed, then including it in the web2py
> website should be as trivial as adding it to the examples-app. Is th
Well, the way I understand it, the admin-app is a web2py app, and so is the
examples-app - which is the we2py website, so assuming the admin-app uses a
component for that tweeter-feed, then including it in the web2py website
should be as trivial as adding it to the examples-app. Is this what you
me
>
> There doesn't necessarily have to be a formal-road-map "process" in
> existence, for there to be a "road-map-section" in the web2py website.
For example, I like how Redmine's road-map section is structured:
> http://www.redmine.org/projects/redmine/roadmap
>
I think you would need a formal
There doesn't necessarily have to be a formal-road-map "process" in
existence, for there to be a "road-map-section" in the web2py website.
For example, I like how Redmine's road-map section is structured:
http://www.redmine.org/projects/redmine/roadmap
There is also an explanation on updating it o
We can update the book as frequently as we like. I think this is the place
for announcements (there's also the Twitter feed). Aside from that, I
suppose we could maintain some kind of framework roadmap document, but we
don't really have a formal roadmap process, and I'm not sure there is a
desi
On the contrary. I think information about testing using web2py, in conjuction
with various testing-frameworks/tools, is highly relevant in the book, along
with common testing-practices, and the way they apply when testing with web2py.
The book, in that case, would act as an information-centrali
On the contrary. I think information about testing using web2py, in conjuction
with various testing-frameworks/tools, is highly relevant in the book, along
with common testing-practices, and the way they apply when testing with web2py.
The book, in that case, would act as an information-centrali
On the contrary. I think information about testing using web2py, in conjuction
with various testing-frameworks/tools, is highly relevant in the book, along
with common testing-practices, and the way they apply when testing with web2py.
The book, in that case, would act as an information-centrali
On the contrary. I think information about testing using web2py, in conjuction
with various testing-frameworks/tools, is highly relevant in the book, along
with common testing-practices, and the way they apply when testing with web2py.
The book, in that case, would act as an information-centrali
On the contrary. I think information about testing using web2py, in conjuction
with various testing-frameworks/tools, is highly relevant in the book, along
with common testing-practices, and the way they apply when testing with web2py.
The book, in that case, would act as an information-centrali
On the contrary. I think information about testing using web2py, in conjuction
with various testing-frameworks/tools, is highly relevant in the book, along
with common testing-practices, and the way they apply when testing with web2py.
The book, in that case, would act as an information-centrali
> Just as an example to how the absent of communication has led to
> porrer-and-unnecessary implementation(s):
>
> In we2py_utils, I've seen Thadeus used 'sqlight:memory' in the
> connection-string. This completely circumvent the entire issue that many
> implementations I had seen have been ha
web2py.test is not mentioned in the book because it's not part of
Web2py. It's a project to make testing app easier in Web2py.
Yes, it's a personal project (by myself), but it's not a nice learning
experience. It's a work in progress to help people develop test driven
apps in Web2py. It's been use
Just as an example to how the absent of communication has led to
porrer-and-unnecessary implementation(s):
In we2py_utils, I've seen Thadeus used 'sqlight:memory' in the
connection-string. This completely circumvent the entire issue that many
implementations I had seen have been hammering on -
You see what I mean?
I had no idea about this thing...
And that is after about a full week's worth of time of research.
This is very telling I think, and is exactly my point.
I hate to be the 'nagging' persona here, but really, my problem is not
about 'working out a solution". My problem is the wi
On Sun, May 19, 2013 at 8:48 PM, Arnon Marcus wrote:
>
> Where is the "ggod stuff"?
The "good stuff" is in our hands and heads. We can join together to
help make it happen.
That's the beauty of open source. Join us and help us develop this
kind of thing, if what exists today doesn't fit your need
> Arnon, how many use cases does your application have?
>
> Is time to run tests really a bottleneck in your case?
>
>
I'm not sure I know how to answer this question, since we have been working
on our code for more than 3 years now, and there is zero testing in it,
currently (which makes me
Arnon, how many use cases does your application have?
Is time to run tests really a bottleneck in your case?
On Fri, May 17, 2013 at 9:07 AM, Arnon Marcus wrote:
> That's good news!
>
> Now the only question that would remain, is weather this means that
> test-performance using this, would be f
That's good news!
Now the only question that would remain, is weather this means that
test-performance using this, would be fast enough for that to be considered
fitting for interactive-TDD...
Otherwise the dal-using-code would still be better-off 'mocked' away...
--
---
You received this m
On Friday, May 17, 2013 6:19:16 AM UTC-4, Arnon Marcus wrote:
> Using this, would it mean that no file is generated in the file-system?
> Does this mean that all that temporary-folder/file jazz would not
> be required?
> In that case, you could even not have to clear-out the tables from
> the pr
On Friday, May 17, 2013 4:23:39 AM UTC-4, Arnon Marcus wrote:
> I have some more questions about using an alternative database for testing.
>
> What would happen to the schema-log file?
> Wouldn't having the same model-code using 2 different databases, mess up
> the log and brake automatic-migrat
Using this, would it mean that no file is generated in the file-system?
Does this mean that all that temporary-folder/file jazz would not
be required?
In that case, you could even not have to clear-out the tables from
the previous test-run, as there wouldn't be any, right?
But it should still req
Another issue:
Testing controller-actions is not considered unit-testing, as it relies on an
external dependancy that is supposed to be generated by the framework.
In web2py it's even worse - you have to prepare an entier execution
environment, as is done in this experiment... Generally, treating
I have some more questions about using an alternative database for testing.
What would happen to the schema-log file?
Wouldn't having the same model-code using 2 different databases, mess up the
log and brake automatic-migration capability?
I mean, you could turn migration off for when testing, b
Well, as an aside, I am planning to use RAMDISK for my new
production-server, as a read-only database.
The approach is to use PosgreSQL's Master/Standby Streaming-Replication
features.
It goes like this:
You have 2 instances of PostgreSQL:
1. Master : For write-only, with a data-directory sitting
+1 !
:)
On Thursday, May 16, 2013 10:37:09 AM UTC-7, Anthony wrote:
>
> I'm not sure how you are goint to implement an in-memory
>> relational-database that can be used woth the same db-object-using code -
>> that sounds ineresting...
>
>
> db = DAL('sqlite:memory')
>
>
--
---
You received
>
> I'm not sure how you are goint to implement an in-memory
> relational-database that can be used woth the same db-object-using code -
> that sounds ineresting...
db = DAL('sqlite:memory')
--
---
You received this message because you are subscribed to the Google Groups
"web2py-users" g
Hi Arnon.
The idea to have an in-memory db is to test a web app the same way Django does.
So, it's up to the developer to choose what must be coded in which
function (or method, or routine). If he/she wants to mix all sort of
rules and accesses, it's possible. If not, it's too. In this case, due
I'm not sure how you are goint to implement an in-memory relational-database
that can be used woth the same db-object-using code - that sounds ineresting...
But this has a smell of having your unit-test testing the framework, more than
your code, the same problem that exists in django.
Ideally
On Thu, May 16, 2013 at 9:18 AM, Arnon Marcus wrote:
>
>
> For unit-tests, people doing TDD want interactive-performance. They
> configure watchers on their files, so the tests run locally each time they
> save them.
> It means, their entire test-suite of unit-tests should run in a
> second-or-two
48 matches
Mail list logo
