On 12/09/14 01:59, roger peppe wrote:
> On 11 September 2014 16:29, Matthew Williams
> wrote:
>> Hi Folks,
>>
>> There seems to be a general push in the direction of having more mocking in
>> unit tests. Obviously this is generally a good thing but there is still
>> value in having integration t
With github I know continuous integration is possible. On another
project I work on we use it. The perk with travis is that it works with
a YAML file plus when a PR is filed it send the patch to be built and
lets you know in the PR if the build was successful or not. I am not
sure though how tha
On Fri, Sep 12, 2014 at 10:43 AM, Gustavo Niemeyer
wrote:
> On Thu, Sep 11, 2014 at 10:42 PM, Andrew Wilkins
> wrote:
> > I basically agree with everything below, but strongly disagree that
> mocking
> > implies you know exactly what the code is doing internally. A good
> interface
>
> I'm also
On Thu, Sep 11, 2014 at 10:42 PM, Andrew Wilkins
wrote:
> I basically agree with everything below, but strongly disagree that mocking
> implies you know exactly what the code is doing internally. A good interface
I'm also in agreement about your points. But just so you understand
where Roger is c
On Thu, Sep 11, 2014 at 11:59 PM, roger peppe wrote:
> On 11 September 2014 16:29, Matthew Williams
> wrote:
> > Hi Folks,
> >
> > There seems to be a general push in the direction of having more mocking
> in
> > unit tests. Obviously this is generally a good thing but there is still
> > value i
On Thu, Sep 11, 2014 at 11:29 PM, Matthew Williams <
matthew.willi...@canonical.com> wrote:
> Hi Folks,
>
> There seems to be a general push in the direction of having more mocking
> in unit tests. Obviously this is generally a good thing but there is still
> value in having integration tests that
The calendar is marked as shared with everyone in Canonical as far as I can
tell. You should be able to go to Add Calendar and type in "Juju Team Calendar"
and it will find it. But it was that long ago when I did it I can't recall the
exact steps.
On 12/09/14 09:44, Menno Smits wrote:
> I don't ha
I don't have a Juju Team calendar set up in my Canonical calendar. How do I
add it? Other newer team members might be in the same boat.
On 12 September 2014 11:28, Ian Booth wrote:
> If you display the Juju Team calendar, you can see who's on what day, plus
> also
> who's on leave and other rele
If you display the Juju Team calendar, you can see who's on what day, plus also
who's on leave and other relevant things like that.
On 12/09/14 09:24, Menno Smits wrote:
> A possibly dumb question: is there any way to see who is on for a given
> day? I can only see my own days.
>
> On 11 Septembe
A possibly dumb question: is there any way to see who is on for a given
day? I can only see my own days.
On 11 September 2014 20:14, Dimiter Naydenov wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11.09.2014 06:12, Tim Penhey wrote:
> > Hi folks,
> >
> > Those of you who are rev
Hi List,
The API server client tests have a new suite, serverSuite, which allow
you to test the api server methods without having to go through the api
client.
This is how to use it:
// old way
func (s *clientSuite) TestSomething(c *gc.C) {
...
// calls via api/client
err := s.APIState.Clie
Last week I added PatchClientFacadeCall to api/export_test.go which does
the same thing: https://github.com/juju/juju/blob/master/api/export_test.go
It is used in several tests, e.g. TestShareEnvironmentExistingUser
On 11/09/14 22:30, Matthew Williams wrote:
Thanks Andrew,
I was almost about t
On Thu, Sep 11, 2014 at 4:06 PM, Mark Ramm-Christensen (Canonical.com)
wrote:
> But they are not the ONLY reasons why they are valuable.
> There are plenty of others -- performance, test-code cleanliness/re-use,
> result granularity, etc.
Performance is the second reason Roger described, and I di
+1!
On Thu, Sep 11, 2014 at 12:59 PM, roger peppe wrote:
> On 11 September 2014 16:29, Matthew Williams
> wrote:
>> Hi Folks,
>>
>> There seems to be a general push in the direction of having more mocking in
>> unit tests. Obviously this is generally a good thing but there is still
>> value in h
So, I believe unit tests are good things.
- They tell you that a specific unit of code works as designed, or does
not.
- They tell you not just that something broke, but where it broke.
- They run quickly and can give you a reasonable level of confidence in
the system very quickly.
Which is probably why they are now blocked here in UAE. They block all Voip
solutions because they charge about $.25 US per minute. I found a
workaround for now at least.
John
=:->
On Sep 11, 2014 7:14 PM, "Nate Finch" wrote:
> https://support.google.com/hangouts/answer/3187125?hl=en
>
> You can
On 11 September 2014 16:29, Matthew Williams
wrote:
> Hi Folks,
>
> There seems to be a general push in the direction of having more mocking in
> unit tests. Obviously this is generally a good thing but there is still
> value in having integration tests that test a number of packages together.
> T
On 11 September 2014 16:29, Matthew Williams
wrote:
> Hi Folks,
>
> There seems to be a general push in the direction of having more mocking in
> unit tests. Obviously this is generally a good thing but there is still
> value in having integration tests that test a number of packages together.
> T
definitely not all in the same package.
On Thu, Sep 11, 2014 at 11:29 AM, Matthew Williams <
matthew.willi...@canonical.com> wrote:
> Hi Folks,
>
> There seems to be a general push in the direction of having more mocking
> in unit tests. Obviously this is generally a good thing but there is still
On Thu, Sep 11, 2014 at 9:10 AM, Frank Mueller
wrote:
> Oh, I have to thank you. Being focussed on the doc directory I simply fogot
> the standard CONTRIBUTING file. Maybe, if it grows more and more, it is
> worth to see this document as a central and quick entry point with
> references into the s
Hi Folks,
There seems to be a general push in the direction of having more mocking in
unit tests. Obviously this is generally a good thing but there is still
value in having integration tests that test a number of packages together.
That's the subject of this mail - I'd like to start discussing ho
Hi Eric,
I was planning on updating
> https://github.com/juju/juju/blob/master/CONTRIBUTING.md once I felt
> comfortable with how reviewboard fit into our workflow. Do you think
> something in juju/doc/contributions, which perhaps elaborates on the
> info in CONTRIBUTING.md, would be a worthy ad
https://support.google.com/hangouts/answer/3187125?hl=en
You can now make calls with Hangouts, calls to US & Canada are free, which
includes the Canonical conference call number. I find this to be really
nice because it means I can use my headset as normal, and don't have to tie
up my phone or u
So, in talking with Eric, he wanted to wait until Monday to get SSL working
at least. He's going to the wipe this weekend and we can start using it
Monday, and Eric will send out an email when it's done.
On Thu, Sep 11, 2014 at 6:59 AM, Nate Finch
wrote:
> This was what you, Tim, and I agreed
On Thu, Sep 11, 2014 at 1:34 AM, Frank Mueller
wrote:
> For switching to a new tool and a new workflow I would like to not simply
> discuss it in a somehow undefined way together with subjunctive terms
> ("Everybody should now ...") here via mail. Please lets fix the workflow in
> a how-to-contrib
I have been in situations in past jobs where adding one field to one
logical entity required changing the signature of a half dozen structures &
functions that were just copying data back and forth for little to no
benefit. This is a pain in the ass, error prone, and should be avoided.
One of the
On 11 September 2014 00:14, Richard Harding wrote:
> On Wed, 10 Sep 2014, Stuart Bishop wrote:
>
>> On 10 September 2014 19:49, Richard Harding
>> wrote:
>>
>> > I think most of the use cases presented so far line up with ours. One I
>> > want to call out as interesting and I hadn't thought abou
This was what you, Tim, and I agreed on in the team meeting. That's why I
signed the message with all our names.
The whole idea was to stop pussyfooting around and just do it. We're not
going to get SSL or redundancy or backups by Monday. We're not going to
use someone else's github credentials
Thanks Andrew,
I was almost about to reimplement this myself - making use of it right now
Thanks
Matty
On Thu, Sep 11, 2014 at 5:57 AM, Andrew Wilkins <
andrew.wilk...@canonical.com> wrote:
> Hi folks,
>
> I'd like to bring a small, recent addition to everyone's attention:
> https://github
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11.09.2014 06:12, Tim Penhey wrote:
> Hi folks,
>
> Those of you who are reviewers should now have invites to your
> bi-weekly review time. This now occurs on the same day every two
> weeks. I have tried to have the mentors on the day after the
>
On 11 September 2014 06:40, John Meinel wrote:
>> ...
>> I have thought for a while that, rather than writing more error-prone code
>> (at > 17k LOC, surely the API code is big enough as it is?), it would
>> be good to create a tool that helps us with the underlying problem -
>> incompatible chang
Nice. And I'm currently have a way to maipulate the registered facades.
Intention is to enable tests for servers running only a V(x) while the
client already reached V(x+1).
I'll describe both in the API Implementation Guide.
mue
On Thu, Sep 11, 2014 at 6:57 AM, Andrew Wilkins <
andrew.wilk...@
For switching to a new tool and a new workflow I would like to not simply
discuss it in a somehow undefined way together with subjunctive terms
("Everybody should now ...") here via mail. Please lets fix the workflow in
a how-to-contribute.md in juju/doc/contributions, so that we easily can
point a
I forgot to say, over the next day or so, as we get more landings to look at,
I'll be going through and editing the document sent out previously, plus marking
bugs as closed if it appears the root cause has been fixed.
On 11/09/14 17:15, Ian Booth wrote:
> Hi folks
>
> It's been a fantastic effor
\o/ Thanks to everyone for the effort.
On Thu, Sep 11, 2014 at 5:15 PM, Ian Booth wrote:
> Hi folks
>
> It's been a fantastic effort so far improving the quality of our tests; so
> much
> so that this time yesterday I switched off the retry flag. This means that our
> landing tests run at full s
Hi folks
It's been a fantastic effort so far improving the quality of our tests; so much
so that this time yesterday I switched off the retry flag. This means that our
landing tests run at full speed, and fail first time if there's an error.
Since the change, I've seen a few failures due to glitc
36 matches
Mail list logo
