October 3, 2024 • 42 mins
In this episode of Adventures in Angular the panel interviews Dave Cooper, who recently gave a talk at AngularConnect about using Mock Data. Dave starts by explaining more about his talk and sharing the benefits of using data mocking solutions and rapid prototyping. He shares the secrets of doing rapid prototyping.
There are challenges to using mock data, Dave shares a few of them and explains how to overcome them. The number one challenge of using mock data is keeping it in sync with your real data and making it look real.
Dave explains how to get started with mock data and shares library recommendations. The panel discusses the use cases for mock data and Dave walks them through a few scenarios for using mock data. He shares use case recommendations and discusses using mock data for testing.
The panel discusses the benefits of using mock data for demos and courses. The possibilities and future of mock data and pact testing are explored. Dave shares his coding process and explains how much faster he can code by using mock data.
Links
Picks
Become a supporter of this podcast: https://www.spreaker.com/podcast/adventures-in-angular--6102018/support.
There are challenges to using mock data, Dave shares a few of them and explains how to overcome them. The number one challenge of using mock data is keeping it in sync with your real data and making it look real.
Dave explains how to get started with mock data and shares library recommendations. The panel discusses the use cases for mock data and Dave walks them through a few scenarios for using mock data. He shares use case recommendations and discusses using mock data for testing.
The panel discusses the benefits of using mock data for demos and courses. The possibilities and future of mock data and pact testing are explored. Dave shares his coding process and explains how much faster he can code by using mock data.
Links
- Mocking made easy | Dave Cooper |
- http://www.davecooper.org/
- https://twitter.com/davewritescodes
- https://www.facebook.com/adventuresinangular
- https://twitter.com/angularpodcast
Picks
- Shai - TestAngular.com
- Shai - https://twitter.com/shai_reznik/status/1202293459207540737
- Shai - Angular 9: Getting Ready To Update to Angular 9
- Dave - https://www.npmjs.com/package/data-mocks
- Dave - Dough: Simple Contemporary Bread
- Younes - https://www.json-generator.com/
- Younes - https://docs.pact.io/implementation_guides/javascript
- Charles - A Christmas Story
- Charles - Holiday Inn
- Charles - White Christmas
- Charles - The Bishop’s Wife
- Charles - Frozen 2
Become a supporter of this podcast: https://www.spreaker.com/podcast/adventures-in-angular--6102018/support.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:07):
Hey everybody, and welcome to another episode of Adventures in Angular.
This week, on our panel, we have Shi Resnik. Hello, Hello, Hello,
we have Eunice. I should have asked how to say
your last name, Let's ask Shy exactly. That's perfect.
Speaker 2 (00:25):
Hello everyone, I'm Charles max Wood from dev Chat dot tv.
I'm kind of excited my book.
Speaker 1 (00:30):
It just came out in paperback on Amazon, so you
can go pick it up Amazon dot com. We have
a special guest this week, and that is Dave Cooper. Dave,
do you want to say hello?
Speaker 3 (00:38):
Hello?
Speaker 4 (00:39):
Everyone? It's very nice and fun to be here.
Speaker 1 (00:42):
Do you want to just give us a brief introduction
who you are? White people know who you are?
Speaker 4 (00:47):
Oh yeah, I'm not too sure anyone knows so I am, but.
Speaker 3 (00:51):
Wow.
Speaker 4 (00:52):
Yeah, I'm the developer living in London at the moment.
I've been here for a few years. Before that was
living in Australia and I guess I just recently did
my first conference talk at Angular Connect this year, which
was a lot of fun. It was just following the
birth of my daughter, so I was unbelievably tired and
sort of had a bit of baby brain through that.
(01:13):
But that was a lot of fun. I do quite
a bit of talking around London, just at various meetups,
mostly around the front end space. That's sort of sort
of the thing that's got my interests very core.
Speaker 1 (01:25):
So, yeah, your talk, if I remember, it was about
doing some sort of like modular design or prototyping and
testing things like that.
Speaker 4 (01:33):
Yeah, so it was basically about I still have trouble
succinctly sort of describing this, which is probably a little
bit of a problem, But basically I see a lot
of developers sort of in the situation where you know,
you might be working by yourself or in a team,
and you've got a new project, and you've got obviously
(01:53):
a lot of fun end and back end components that
need building, and I see a lot of people do
some naughty things around how they are deal with data
in their applications. So you know, people connecting out to
production services to test features that they're developing locally on
their machines or things like that. And I think that
(02:15):
a lot of people seem to be avoiding using decent
I guess mock solutions, like data mocking solutions these So
I sort of talk about that and try to encourage
people that it's a lot faster to use mock data,
so it's a lot safer I guess as well, because
you're not touching things that you shouldn't. I'm all about
rapid prototyping or just getting code out there in front
(02:37):
of people, and I find that working like that allows
me to be able to achieve that goal, and so
I sort of, I guess, preach a little bit about
that and it usually generates some pretty fun discussions.
Speaker 2 (02:48):
So what are the secrets?
Speaker 4 (02:49):
Right?
Speaker 2 (02:49):
What are the secrets to doing this? Kind of.
Speaker 4 (02:54):
The secrets?
Speaker 2 (02:54):
I think prank faster, right, Yeah, that's it.
Speaker 4 (02:58):
Just work faster, write more, write less bugs. I think
that this is definitely one of those things that you know,
there's always some cool new thing in the front end
space every every week or every month, and I think
when it comes to data marketing solutions that sort of
stay quite stagnant for you know, the better part. I
know of pretty much this decade, there isn't really much
(03:20):
I guess, innovation happening in that space. But I think
that there are some libraries starting to emerge, and I've
written one myself as well, that just allow you to
as simply as possible, you know, specify what endpoints your
front end application is going to connect out to and
what sort of data you want back from when you
request something from one of those resources, but then also
(03:43):
have the flexibility to say, you know, let's just say
that we're working on a banking app and we want
to be able to pull up a customer that you know,
maybe they've got three different accounts or three different bank accounts,
two of them are in credit, one of them's in debt,
and they've got a late pain. And if you don't
have some sort of data marcking solution in place for that,
(04:04):
you need to tink around with databases, or you need
to have some test account that could be in whatever state.
And I think being able to really quickly and reliably
manipulate application state without having to mess around with databases
or connecting out using real customers in production or your
staging environments and things like that, I think that that's
(04:25):
sort of like a very overlooked thing in the front
end space. I think it's so handy and it's such
a nice developer experience when you start to contribute to
someone else's code base and all you have to do
to be able to get things up and running is
clone their code and stare dependencies and immediately you can
start doing things with it. Rather than having to ask
a lot of questions about how can we pull up
(04:45):
the application in a particular state.
Speaker 5 (04:48):
Just have one question here. What would be the challenge
if you want to sync like your remugs with your
real API, like keeping it use like the same I
don't know, like furies in open API or as ry. Yeah,
is this like a challenge? What's the cost?
Speaker 4 (05:03):
Yeah? So it is a challenge. I think you've you've
got two different routes sort of down this path. One
of them is that you just accept that there is
the possibility that your your data, like your your local
data and your MAX might get out of sync. And
you'd sort of hope that someone would notice that that's
not foolproof, and you know that can obviously lead to
(05:24):
problems because you're developing it gets one thing locally and
that's not what's in your staging or production environments. There's
also tooling out there that can allow you to sync up,
as you mentioned before, like Swagger specifications and generate mocks
off the back of that. There's loads of things that
do that, and I think that I'm starting to see
a little bit more use of it around the place,
(05:45):
Like even in my current workplace. The other day, someone
came up to me and was like, Hey, check this out.
You can actually generate, you know, a mock server off
the back of a Swagger specification, and it's really cool
to see people doing that. I think that it is
probably one of the biggest challenges in this space though,
because people really like actual data, or at least data
(06:06):
that looks like it could be production data. Like you
don't want random garbled strings for people's names and addresses
and and really large numbers for things like a banking
banking app, where realistically the numbers are a lot smaller
than things like that. So yeah, it is a real challenge,
but I don't think it's an insurmountable one.
Speaker 3 (06:27):
Okay, so sorry if I miss that before.
Speaker 6 (06:31):
But what are the steps, Like, what do the listeners
can do in order to start and benefit from it?
Speaker 4 (06:39):
Yeah, I mean the first thing that I'd probably say
is if you're connecting out to a production or staging
service to develop your apps locally, I'd probably recommend downloading
any mock library. Yeah, anything that there's loads of them
off at NPM I've written one called data Marks that's
starting to get a bit of a bit of traction
at the moment, which is really good. I'm seeing contributions
(07:02):
from the community, but just getting one of them. I mean,
there's loads of really really popular ones as well. You've
got things like Jason Server, which I mean, I'm not
one hundred percent sure how many hits that gets, but
it must get at least one hundred k downloads a week,
and just get your application to connect out to that,
and I think you can immediately start seeing the benefits
of it. Like a lot of these mocking solutions as well,
(07:25):
they don't even spin up. Not a lot of them,
but some of them don't even spin up like an
extra service. Like you've got data Marks, which is as
I said, the library that I wrote earlier, it leverages
intercepting fetch and h XHR requests, so not even running
an extra service. So if you've got a really low
(07:45):
end laptop like myself, which really struggles to run most things,
you know, it's not an extra thing, which is like
chewing up your CPU and battery.
Speaker 6 (07:52):
Yeah, first of all, all someome job on grading the library,
and I just want to clarify the term is thrown
around a lot, and it means several things in the
world of testing. So just to clarify it, we're talking
about fake data.
Speaker 4 (08:10):
Yeah, that's a really yeah, that's that's a really good point. Actually, Yeah,
that that term does get thrown around in the testing
space a lot. Yeah, we're talking about, yeah, fake data.
So we have a request, you know, to Dave's cool
api dot com slash foo, and when we hit that endpoint,
we're expecting a particular response back, and that response is
(08:31):
what I'm referring to as the market it's the mock
response to that request.
Speaker 3 (08:35):
Yeah, so that's a differentiate in like testing.
Speaker 6 (08:38):
When we're talking about mark smock objects, we're usually talking
about like stuff that has assertions.
Speaker 3 (08:45):
Built into them, so if you don't get the stuff
you you expect, it throws an error.
Speaker 6 (08:52):
But when you talk about just getting like fake data
or just like you know, just running a method and
not like doing anything just so it will satisfy the compiler,
we're talking about stubs. So that so just like getting
the data just to display on the screen the list.
Speaker 3 (09:11):
Of puppies that you want to display.
Speaker 6 (09:13):
It's probably it's more like like a stub to those
on you of you who know like that term, So
that's what we're talking about, like fake data, And just
to clarify.
Speaker 1 (09:23):
Yeah, no, that's a that's a very very good point there. Yeah,
definitely right, and that you know, just to reiterate that.
The idea then is, yeah, then you don't have this
back end system that's chewing up more CPU or memory
and you can just focus on your Angerer app.
Speaker 4 (09:38):
Yeah. And I find that not having it because I mean,
it really depends the sort of developer you are and
what where your interests lie as well. But I think
I see it in a lot more junior people as well.
As you know, you're working on a you know, you
might be on a product team at work, and your
team might be split one of many ways, but you
might have front end specialists and back end specialists in
(09:59):
your team. And I do notice that there are certain
I guess there are certain types of developers that like
prefer to stick into their own space, so they prefer
not to have to write endpoint like back and end
points themselves, or maybe they just don't know how to
or whatever. I find that sometimes you hear things like oh,
(10:19):
I can't work on that yet, because the API is
not ready for that yet. And that's one of the
perfect use cases for using these sorts of things is
that you don't actually require a single line of back
end code to be written, and you can already complete
the front end components without a single line of back
end code being written.
Speaker 3 (10:39):
Yeah, that's a very good scenario for that.
Speaker 6 (10:42):
Have you talked about again, sorry if I mean, say,
I had some technical issues with like audio and stuff,
so I didn't hear some of the earlier comments. Did
you talk about what happens once you have the data,
like the real data, do you like still integrated or
just at that point you just like lose the mock
(11:03):
data and then switch over to using the you know,
the real one, or like, what's this strategy there?
Speaker 4 (11:10):
I guess the strategy there is that whatever solution that
you're using, is that you would only really want to
be using these mocked responses when you're developing your application locally,
so that when you're making a build for your staging
a production environment, that you're you're no longer using these
these mock services anymore. So there's a few ways that
(11:32):
you can do that, Like in the entry points to
your application, you can always do a check to see
if you're in a development environment, and then from there
you can dynamically choose to dynamically import your mock libraries
or your mock services, and then that way it doesn't
affect your bundle size when you're making production builds and
things like that.
Speaker 3 (11:52):
Cool nice.
Speaker 6 (11:53):
And for testing, like let's say, unit tests and stuff,
do develop weed that or you just just for development purposes.
Speaker 4 (12:03):
I've found that the strategy that works me is just
using it for development purposes, because when you're writing unit tests,
you know, most of the time i'd gather you know,
you're not necessarily writing unit tests that are unit testing
things that make HGTP calls. And if you are, that
is a simple thing that you could use now I'm
(12:24):
using the term I guess again, but you could use
a mock library for that. For instance. You know, if
you're using jest or mocker or anything like that, you
know you could mock those directly in your unit tests.
Speaker 2 (12:38):
You can also have your CI run your end end
tests and.
Speaker 6 (12:40):
Yep, yeah, most of them. You probably wouldn't want to
unit test your outer layer of your client app. You
probably want to write integration tests there just to see
that your client is talking with the back end in
the right way, and it's not like really helpful to
(13:03):
you know, mock up stuff that you don't really you
can really control. But that's the topic for another episode.
Speaker 3 (13:11):
I guess.
Speaker 4 (13:12):
Yeah.
Speaker 5 (13:13):
I got a question, like before like diving into like
the testing part. If we dive into it, if we're
like developing the app and creating like this fake data,
would you recommend having like a fake data set for
the whole app or do you have like fake data
sets for each context? So like, okay, let's let's suppose
(13:37):
we're in this state and I'm going to load this
fake data and I'm going to try my app with
this fake data, or do you have like global fake
data that you use all the time.
Speaker 4 (13:48):
I found that maintaining a list of like I refer
to them myself just as fixtures. It's probably not quite
the right term for it, but basically, I mean it's
sort of a little bit of both. I've found that
you know, you've got your in the library that I've written.
I refer to them as scenarios, so the application will
have I guess what you would refer to as the
(14:09):
default scenario. So that is like your happiest path that
your application could have. You know, you use the logs incorrectly.
You know, they can view their account information, they can
make you know whatever changes they want, and there's no
sort of error states or weird edge case states. And
then you introduce the concept of a scenario, which is
(14:30):
sort of starting to handle these edge and error cases.
And I've seen different libraries handle these things different ways,
but usually at the end of the day, you define
your default scenarios or like your your happiest path for
how you use your application, and then these scenarios get
merged into that so that you get everything that happens
(14:50):
in your default scenario plus whatever you define in this
edge case, maybe there's like a maybe there's like a
log in error or something like that, or maybe that's
not the greatest example. Maybe we're already logged in, so
that's part of our happy path, and maybe when we
try to view our account information for account number two,
there's some sort of five hundred error from the server,
(15:12):
so that would be part of I guess the set
of mocks for that edge case scenario or error case scenario.
And then when you're using your app, when you're developing
your app locally and you're trying to test that out
and see how things behave you know, you'd expect that
your app would probably do have some something to handle
what happens when we get some sort of error from
(15:33):
the server.
Speaker 5 (15:34):
Thanks, that's a very good question. This, Thank you very much, Shy.
I'm trying hard.
Speaker 3 (15:41):
I know I'm here to support.
Speaker 5 (15:43):
Thank you. Let's still have another question, can I go,
yeah on a roll? Okay, so it's quite the same topic, like,
would you like considering in developing like an angler app
and and I want like some fake data for my
happy past? Would you recommend using a fake library like
(16:06):
yours to have like fake HCP responsors or would you
recommend fake services with the same interfaces and like that?
Can I don't know, change the data in memory or
in a store or anything.
Speaker 4 (16:19):
So that Yeah, that was an interesting that's an interesting one.
So how this all started for me is I had
this problem for the first time, which was, Hey, I'm
starting a new application from scratch, and I don't want
to have to talk to services that you know, either
exists in a live environment or they haven't been written yet.
And that's I sort of got led down that path,
(16:40):
and I was introduced This is back when I was
still writing Angular JAS, and I was introduced to a
library called Angular Multi Marx and that does it basically
behaves the same way that data Marx behaves, except data
Marx is framework agnostic. And so when I was writing Days,
(17:01):
I think I first used it for a React application.
I'm not sure if I'm allowed to say React or
if that's going to get beat down for me. Yeah,
I'll get dumped from the coal in a second. And
I remember it working really nicely because to sort of
like bootstrap a React application. It's slightly lighter on code
than what the Angular Cli generates. But the truth of
(17:24):
the matter is that it doesn't matter what framework you're
using or anything like that. There's always an entry point
to the application, and the developer almost always has access
to that entry point. And for instance, the way that
data max works with it is all you need to
do is call a function called inject max and you
(17:44):
through to that function. You pass through the set of
scenarios that you want to use with your application. So
it's very unintrusive. So I guess to answer your question, yeah,
I would recommend using something like data max or something
that if you prefer to go down on the path
that has something that actually spins up something like a
node service or any HGTP server. You could use something
(18:07):
like a Jason server or API mocker, or you know,
there's there's so many different things, but it's an unintrusive
way of integrating it with your application while still having
that freedom to have I guess the idea is when
you build or deploy it to a different environment that
you're not stuck with that mock solution. You can sort
(18:28):
of build it out of your application as well.
Speaker 5 (18:31):
Okay, so your recommand are like to use fake data
at the HTP level, so it's framework agnostic and you
can reuse it somewhere else.
Speaker 4 (18:41):
Okay, yeah, absolutely, And it just it makes life so
much quicker and easier, especially if you're trying to prototype
something or spin up a new project that you know
it's going to stick around for a while, or even
if it's not yet as just said, even if it's
just prototyping. I just think that it's such a fast
way to get code written and immediately start you know,
(19:03):
really being able to focus on the front end space.
Speaker 5 (19:06):
Thanks.
Speaker 1 (19:06):
Yeah, so what's the cycle that you follow. I mean,
are you're doing TDD. Are you you know, build test,
build test.
Speaker 4 (19:14):
Yeah, that's a that's a good question. I'd probably be
lying if I said that I always do TDD. But
possible blasphemy again, but.
Speaker 3 (19:23):
That's for me.
Speaker 2 (19:26):
Shy is the only one you'll make cry with them. Sorry,
I'm gonna leave.
Speaker 3 (19:30):
No.
Speaker 4 (19:31):
I think it really depends for me on the project
and the nature of the work. For simple crowd applications,
I'm probably less inclined to follow a more hardcore methodology.
For projects that I'm joining and contributing to, I'm probably
more inclined to do it. I find that a lot
(19:52):
more of my work these days. I'm really enjoying a
lot of projects that I contribute to these days, U
Cyprus for the for the UI and all of that,
And I'm really enjoying the idea of writing Cyprus tests first,
so that and making them fail and then building against that.
I find that that's been a really I guess effective
(20:13):
way that works for me. But I think it's such
a difficult question to answer because there isn't a silver bullet.
There's nothing that works perfectly for everyone.
Speaker 1 (20:23):
Yeah, that's a very BDD to me, which is behavioral development,
which is you build the big story first and then
you cycle and you get the steps out with your
unit tests.
Speaker 3 (20:34):
Yeah, yeah, most of that.
Speaker 6 (20:36):
I find that the writing test after the code is
good when you are exploring like a new and you
think that you're still not sure how it looks like
how the API behaved, you don't really know the API yet.
Some people preferred to do it in TDD that like
those scenarios. I find it too confusing because I need
(20:58):
to like focus on the test and learning a new API.
But once I learn, like once I know the API,
I switch the order and then it's much easier to.
Speaker 3 (21:08):
Oh, I know that this is how it behaves like this.
Speaker 6 (21:11):
Library or something like that, or this like thermac, and
now I know how to write my test to test
my logic.
Speaker 3 (21:18):
Only my logic uses this or something like that.
Speaker 6 (21:21):
But I find it also another scenario to use I
don't know if it's that common, but to use like
a fake data libraries like like you mentioned and Jason
server is when doing demos like for talks and for
courses and you know, workshops. That's the best scenario because
nobody has to like now download postgrass or you know,
(21:45):
install like a database or even know what like you know,
it reduces all the complexity, So that's another good use case.
Speaker 4 (21:54):
Absolutely it's a sort of education side and the demo
side is absolutely great. You also you're in full control,
like you're reducing the number of points of failure and
reducing the complexity.
Speaker 5 (22:08):
Yep.
Speaker 2 (22:09):
Have you done anything with storybook?
Speaker 4 (22:11):
Yeah? I love storybook. I've just spun up a new
project in the last couple of weeks where we've had
quite a few contributors towards it from the basically day one,
and we've found really really effective use of storybook to
sort of any sort of shared component goes in there
and it's very quick. You know, I can say say
to the gang, you know here, I've developed this. It's
in storybook. You can use it if you want, or
(22:33):
you can you can tweak it. So I've found a
lot of success and it's also in the past as well,
but this has been the most effective sort of use
of it I've seen where you've got loads of developers
from the beginning on something and you know, you don't
want to be building the same thing multiple times and
having that soundbox environment from the get go has been
really really helpful.
Speaker 3 (22:54):
Cool.
Speaker 5 (22:55):
We got one little question about consumer driven contract with
I don't know, libraries like BACKED. I don't know if
you're familiar with that, and if you are. For instance,
when I use BACKED, I usually use that in my
integration tests, for instance, and it generates the facts for
(23:16):
the back end. But would that be possible to integrate
that with your fake data library or something?
Speaker 4 (23:25):
It might be. I've not done it myself. I think
I've probably I'm probably falling into the category of people
who haven't seen PAC testing being used very effectively in organizations.
I think that the the theory, like how it works
and what it's used for is like very sound. I'm
just I just don't think that I've really been exposed
(23:47):
to anyone, like any organization that does it well. But
I'm sure there's a million people out there that can
tell me that they love it in terms of using
it with these sorts of like fake data libraries. I'm
not one hundred percent sure whether or not that's I
don't know what the right word is, whether there's a
decence or not yield from that to make it worth
(24:08):
the effort. But maybe the rest of the game here
have some other thoughts.
Speaker 6 (24:13):
Yeah, I think that like the future is in the
connectivity between those two points. Like you already have your
fake data which has a schema you know, like shape,
and you already have like if you're going to I
think that again, the future is in like stuff like Packed.
I don't know if pact itself because it's still like
(24:34):
like in I feel like a proper node server table
like for testing and stuff like that still like uses
the thing the Ruby application behind the scenes, which.
Speaker 2 (24:46):
I can confirm.
Speaker 6 (24:47):
Yeah, so, but the idea behind it I think is
very very very useful, And to those of you who
don't know what it is.
Speaker 3 (24:58):
Check out packed JSPA.
Speaker 6 (25:00):
Basically, it means that you have contract tests between your
client and your server, and when you mock out your
server like with instead of using like just fake data
without any connection to the server side, you actually use
fake data and that fake data and or the contract
is being generated as ad Jason, and then on the
(25:24):
service side they take this Jason and run it through
like as an API call to the server to test
if the server returns what the contract says it needs
to return and if not, you see an integration problem.
Speaker 3 (25:38):
And that's a.
Speaker 6 (25:40):
I feel that's a much more scalable approach rather than
like using integration tests or end to end test because
those can cover just you know, a small chunk of
your logic because otherwise, for an enterprise application, for example,
it can.
Speaker 3 (25:57):
Take like two hours. I don't know to run all
the scenarios and everything breaks all the time, But I don't.
Speaker 6 (26:04):
I feel like we're only just beginning, Like I don't
have like a go to solution now because I think
there's still much more work to be done. But I
feel that PACKED is a cool organization, like the people
behind it.
Speaker 3 (26:18):
They are open, they have a cool.
Speaker 6 (26:22):
No it's not slack, I think it's a guitar channel
or no, they have also a slack channel and very
open to collaborations and contributions.
Speaker 3 (26:33):
So that's my bit.
Speaker 6 (26:35):
But I think the connection between like the fake data
and something like PACKED or contract testing this is the
obvious thing because you.
Speaker 3 (26:42):
Already have it.
Speaker 6 (26:44):
It's like I think they have there's a strong connection
that they want to work now on in trying to
solve which is between story books and unities because both
have use cases, Right, you describe use cases in your storybook,
like which flags can you like turn on and stuff
like that, and now it behaves, which basically the same
(27:05):
setup in the unit test. You set up the same
stuff in the unities. So like the connection between them
is something I'm exploring right now and trying to maybe
do something new with them. But more on that later
on when I have some POC to show.
Speaker 5 (27:23):
But by the way, concern impacts for those who want
to try, like in fact, like shy, Like I don't
know if I'm gonna take it with me on this,
but you know, I'm not a big fan of like
the real implementation because like pacts is really based on
running a packed server next to your app and then
running a PACT client to test your API, which is
not very unit tests and friendly and paralyzation friendly, and yeah,
(27:49):
it breaks a lot and it brings a lot. So
I've been experiencing things where you what I love about
PACT is the pact specification, Like the JSON file that
came the schema is really nice and it says like
I'm expecting this request and I'm going to respond this
if I'm in this state and I'm not aware of
(28:09):
any library. I've just been experimenting things and maybe you.
Speaker 6 (28:14):
Can you're working on something that they will general to
generate the files without going through the server.
Speaker 5 (28:21):
Yeah, the idea is to make something that doesn't especially
doesn't need the client. What I want to mean by this,
I'm not like putting out like I'm not teasing about anything.
I'm just saying that. I'm just saying that Packed. If
you're not satisfied by packed jas like server and all
(28:43):
the perform a didos attack on them, maybe maybe we
need some libraries that handle the specification. So keep an
eye on Like the Packed specification. The scheme is really nice,
and the way they did it, I think there's something.
I joined Chai on this, like there's something we can
we can do there to join, like all this fake
(29:06):
data with the swagger and the fact there is something,
there is something to do.
Speaker 3 (29:11):
This is the future. Yep, you heard it here first.
Speaker 5 (29:19):
I said it before, but I was along with my cat.
Speaker 1 (29:25):
With my cat, we're kind of getting toward the end
of our time. Is there anything else that we should
make sure we cover here?
Speaker 3 (29:32):
How long it took you to grow this beard?
Speaker 5 (29:35):
Dave?
Speaker 4 (29:35):
Oh, yes, you can see this. I'm not too sure
because I do trim it quite a bit. I've thought
it for quite a few years now, most significent, Thank
you very much. I always enjoy a beard conflict. There's
about there's about eighteen chins underneath this beard.
Speaker 5 (29:51):
I think.
Speaker 3 (29:54):
You're you're in good company.
Speaker 1 (29:58):
I'm kind of curious how much how much more quickly
were you able to move using this technique?
Speaker 3 (30:04):
Boller?
Speaker 2 (30:05):
Do you just feel like you're manfester.
Speaker 4 (30:07):
The beard or the mocking solutions.
Speaker 3 (30:10):
Marking the beard the beard? How quickly?
Speaker 4 (30:14):
Yeah, it's much less. I feel like I mean, personally,
it just feels like I'm not blocked by anything to
do with data. I can make it exactly what I
want when I need to. And you know what, you know,
if I am just spinning up a new project and
I'm waiting on some backend work to be done round
waiting on myself to implement some endpoints, you know, I
(30:35):
can right the front end and i can develop my
features or fix my bugs or whatever. And let's just
say that there's nothing in place to enforce any sort
of integrity between what fake data I'm using and what
the actual schema it's going to look like most of
the time, and by most of the time, I mean
ninety nine times out of one hundred, I can take
a pretty good guess at what it's going to look
(30:57):
like anyway. And you know, if it turns out that
there's an extra field that's coming back in the response
body of a particular request that I need to be
mindful of, or I've met like I've given something the
wrong name or whatever, you know, that's a very quick
and easy fix. So I guess to answer your question directly,
it feels many orders of magnitude faster. And anyone that
(31:20):
I've sort of introduced to this or spoken about or
implored to use that's sort of engaged in any sort
of conversation, you sort of you see them have that
sort of moment where they realize just how helpful this
sort of stuff is. I don't really think that everyone
is aware of these sorts of techniques and that they
aren't complicated to set up, and they're not invasive in
(31:41):
your own code base, and you sort of see them
have that sort of Eureka moment, the light bulb turns
on and all of a sudden, this is great. So yeah,
I guess that's probably the best answer that I can
give you for that nice But the way.
Speaker 3 (31:55):
Have you talked about other generating like.
Speaker 4 (31:58):
Yeah, so I'm I'm currently I've just about written a
finished writing a Chrome plug in that I can make
it record and requests that I'm making and capture actual
requests and export them as marks to use nice, which
is really really nice. I'm hoping to get that published
pretty soon and I'll be spamming that on on social
(32:21):
media and trying to get people now in that as well.
Speaker 5 (32:25):
I'm away retweak excellent And by the way, I also
have like a real quick question concerning recommendation. Would you
recommend using like static fake data like as static as possible,
or would you recommend using like some dynamic features like
(32:45):
things we can see with the Jason server, Like would
you hard code like slash user slash user ID and
the response are Would you recommend like writing dynamics stuff
like add some a little JavaScript to the Jason server.
Speaker 4 (33:02):
That's a good question. I guess it depends on what
data you're dealing with. But that sort of leads into
other conversations as well, Like you've got certain things that
you know they're pretty static, like someone's name is pretty static,
someone's account balance is not so static. But even for
the things that are really static, you know, you then
get you then delve into the territory of I can't
(33:25):
remember what the exact term for it is, but you know,
we're talking about, well, what if you've got a really
really long name or really really short name sort of
catching those sorts of boundaries. What happens when your applications
using a language that is, instead of left to right,
it's sort of right to left sort of language. And
you've got those sorts of you know, and now you've
got got to deal with really short and long names
(33:45):
and see how how you interface behaves with that sort
of stuff. So I guess I can't really directly give
you an answer there. Most of the time I tend
to stick with really static things, but I guess it's
definitely very valid ton stead of using a more dynamic
approach as well, it probably helps you test a wider
range of things.
Speaker 5 (34:06):
Thanks.
Speaker 2 (34:06):
Okay, all right, well let's go ahead and use the picks. Shy,
do you want to start us off with the picks?
Speaker 6 (34:13):
Yeah?
Speaker 3 (34:13):
Yes, Jack.
Speaker 6 (34:17):
First of all, I want to pick so Angikov did
this live call when they talked about IV and how
to prepare to angular for angular and nine how to
prepare right now before the announcement, so check it out.
Speaker 3 (34:36):
I will put a link.
Speaker 6 (34:37):
And also recently I retweeted or I tweeted this short
video by Angela you where she talks about her approach
to like focus on things you can change and be
in a role model. Really cool short video teaches I
(34:58):
think iOS and how to develop apps for mobile.
Speaker 3 (35:03):
So I'll put that as well. And those are our.
Speaker 2 (35:07):
Picks nice units you have to picks for us.
Speaker 5 (35:12):
So I have this link. It's Chase on generator dot com.
It's just I thought about it because it's related to
the topic, like it's really nice. I don't know if
you know about it. It's a little online tool to
generate fake data that doesn't look like full bar, you know,
something more realistic. It has generators for company names and
(35:35):
cities and things like that. And the other the other
pick is a random code from canspeg like father of
Extreme Programming, which is quite related to what we're talking
about here today about tests and things like that. It
just says like that developing an application is just like
a boat with a hole in it. If you keep
(35:58):
rowing like you end up under the water. But if
you just keep on like taking the water out of
the boat. You're not moving, so it's like an equilibrium.
And that's what I like about the approach of Dave Cooper. Okay,
we're not like TDD and everything. We're not just like
it's not perfect, but anyway, we're moving forward, we're moving fast,
(36:19):
and we're keeping it clean anyway, you.
Speaker 3 (36:21):
Know, awesome.
Speaker 6 (36:21):
By the way, I want to mention that Canback has
a nice little video series now on YouTube on his
channel where he talks about testing. You need testing, I think,
And one thing that he mentioned which really makes make
sense to me was not treating your code, your testing
(36:43):
code as production code, which is countering most beliefs that
I heard before, like keeping your tests dry and all
that stuff. It actually creates more problems when you try
to keep things dry and you end up not understanding
what the tests are doing.
Speaker 3 (37:00):
So that's kind of a nice way.
Speaker 6 (37:02):
And now this and I don't know counter approach to
look at your tests and try not to dry everything
and make everything you still just think about what you
are drying and what you're keeping in like in front
of the developer who write the test or maintain the test.
Speaker 3 (37:20):
So that's one thing.
Speaker 6 (37:21):
And by the way, I've forgot to mention in my piks,
let me like hijack one quick. I have like a
free workshop on like the types of tests and stuff
like that, so you could like sign up on testangler
dot com and when it will be released again you
will get a entification. But I'm talking there about like
you know, the contract tests and all the stuff that
(37:42):
we talked about this episode. Just forgot about it. So yeah,
testanglar dot com.
Speaker 2 (37:47):
And that's it for me, Nice Unice, anything else from you?
Speaker 5 (37:52):
Oh, that's it for today.
Speaker 3 (37:53):
Okay.
Speaker 1 (37:54):
I'm always like eager to go and then I'm like,
am I cutting them off? So awesome. I've got a
couple of picks here. The first one is Man on
the other shows I've been doing Christmas movie picks, but
I think we might be a little bit too late
on that. I'm gonna throw it out anyway, and we'll
just see where it goes. If you get this right
after Christmas watch them anyway. So I'm just gonna pick
four or five Christmas movies that I really really love.
(38:16):
These were spread out over several weeks on like JavaScript
jabber and stuff, so if you've already heard them, I'm sorry.
Speaker 2 (38:21):
But there you go.
Speaker 1 (38:22):
Some of the movies that I think everybody should watch.
I think my favorite one of all time is A
Christmas Story, and that's just a classic movie, tons of
one liner's funny scenes.
Speaker 2 (38:32):
I mean, just a terrific movie.
Speaker 1 (38:35):
So if you haven't seen it, I think it came
out in nineteen eighty three, definitely check it out.
Speaker 2 (38:39):
And then the.
Speaker 1 (38:40):
Rest of these are going to be a bit older.
The first one's called Holiday Inn. It's the first movie
in which the song White Christmas appeared. And yes, there
is a movie called White Christmas. Both movies actually have
Bean Crosby in them, and he sings the song in
both movies. They're both terrific. One was made in the
forties and one was made in the fifties. Holiday Inn
(39:00):
has Being Crosby and Fred Astaire in it, so a
little bit more dancing and zinging and stuff. There is
plenty of singing in White Christmas though, and it features
Danny Kay, and Danny Kay is hilarious. So if you
want to go look up other older movies that are
worth watching that are freaking funny, just go find anything
with him in it, because they're awesome. And then another
(39:21):
one and This is an old movie. It's a Kerry
Grant movie. It's called The Bishop's Wife. Basically, it's this
bishop he feels called to build the cathedral in the town,
and so this angel appears and you know, kind of
interacts with him and his wife. Anyway, it's a terrific movie.
I'm not going to spoil too much more of it,
but yeah, it was pretty awesome. And then my mom
(39:44):
took us all to see Frozen two, so I'm going
to pick that. It's not a Christmas movie, but it
was terrific and my favorite part was the Lost in
the Woods song. If you grew up as part of
my generation, you'll enjoy it. That's all I'm going to
say about that. Dave, Do you have some picks for us?
Speaker 4 (40:00):
Yeah? I was going to be really self indulgent and
just pick the Mocking Library that I wrote as a pick,
but no, no, no, no, no, I can't do that.
Speaker 2 (40:11):
And then pick that mouse all right, I'll pick.
Speaker 4 (40:13):
That Data Marks. You can get it off NPM. If
you do, give it a go, and if you love
it or hate it, please let me know. I'm always
up for contributions or discussions or suggestions. I love all
of that stuff. But I think I'll pick another thing
which is not along these sorts of lines. But I've
(40:35):
recently just returned to working after about three and a
half months off because my baby was born and I
had the opportunity to take some time to time off
work to sort of learn how to take care of
a human. But during that time I got really big
into baking bread and it's unbelievably satisfying putting in the
(40:58):
effort and the hours to getting a really good loaf
of bread baked. So there's a guy who lives in
Bath in the UK called Richard Bertone, and he's got
a book called Dough and that would be my pick.
I've done a bread making course with him before, but
he is like the bread god. He really understands all
(41:19):
of that stuff. So my pick will be baked some
bread and read that book.
Speaker 5 (41:25):
Nice.
Speaker 1 (41:26):
I love cooking. So yeah, that's right at my alley.
If people want to find you online, where are you?
Speaker 4 (41:32):
I'm on Twitter. I'm not super active, but that's just
because I don't think many people want to read my ramblings.
But my Twitter handle is at Dave Wright's Codes with
an S on the end. There you can also see
my blog at Dave Cooper dot org or shoot me
an email on Dave at Davecooper dot org.
Speaker 1 (41:52):
Nice, all right, well we'll go ahead and wrap up,
but thanks for coming and talking to us.
Speaker 4 (41:58):
Yeah, thanks so much for having me.
Speaker 2 (41:59):
That was a lot of fun and thanks for filling
in with this unis.
Speaker 5 (42:02):
Thank you, thank you for having me.
Speaker 1 (42:04):
All right, folks, Well, yeah, we'll have another one next
week and in the meantime max out
Hey everybody, and welcome to another episode of Adventures in Angular.
This week, on our panel, we have Shi Resnik. Hello, Hello, Hello,
we have Eunice. I should have asked how to say
your last name, Let's ask Shy exactly. That's perfect.
Speaker 2 (00:25):
Hello everyone, I'm Charles max Wood from dev Chat dot tv.
I'm kind of excited my book.
Speaker 1 (00:30):
It just came out in paperback on Amazon, so you
can go pick it up Amazon dot com. We have
a special guest this week, and that is Dave Cooper. Dave,
do you want to say hello?
Speaker 3 (00:38):
Hello?
Speaker 4 (00:39):
Everyone? It's very nice and fun to be here.
Speaker 1 (00:42):
Do you want to just give us a brief introduction
who you are? White people know who you are?
Speaker 4 (00:47):
Oh yeah, I'm not too sure anyone knows so I am, but.
Speaker 3 (00:51):
Wow.
Speaker 4 (00:52):
Yeah, I'm the developer living in London at the moment.
I've been here for a few years. Before that was
living in Australia and I guess I just recently did
my first conference talk at Angular Connect this year, which
was a lot of fun. It was just following the
birth of my daughter, so I was unbelievably tired and
sort of had a bit of baby brain through that.
(01:13):
But that was a lot of fun. I do quite
a bit of talking around London, just at various meetups,
mostly around the front end space. That's sort of sort
of the thing that's got my interests very core.
Speaker 1 (01:25):
So, yeah, your talk, if I remember, it was about
doing some sort of like modular design or prototyping and
testing things like that.
Speaker 4 (01:33):
Yeah, so it was basically about I still have trouble
succinctly sort of describing this, which is probably a little
bit of a problem, But basically I see a lot
of developers sort of in the situation where you know,
you might be working by yourself or in a team,
and you've got a new project, and you've got obviously
(01:53):
a lot of fun end and back end components that
need building, and I see a lot of people do
some naughty things around how they are deal with data
in their applications. So you know, people connecting out to
production services to test features that they're developing locally on
their machines or things like that. And I think that
(02:15):
a lot of people seem to be avoiding using decent
I guess mock solutions, like data mocking solutions these So
I sort of talk about that and try to encourage
people that it's a lot faster to use mock data,
so it's a lot safer I guess as well, because
you're not touching things that you shouldn't. I'm all about
rapid prototyping or just getting code out there in front
(02:37):
of people, and I find that working like that allows
me to be able to achieve that goal, and so
I sort of, I guess, preach a little bit about
that and it usually generates some pretty fun discussions.
Speaker 2 (02:48):
So what are the secrets?
Speaker 4 (02:49):
Right?
Speaker 2 (02:49):
What are the secrets to doing this? Kind of.
Speaker 4 (02:54):
The secrets?
Speaker 2 (02:54):
I think prank faster, right, Yeah, that's it.
Speaker 4 (02:58):
Just work faster, write more, write less bugs. I think
that this is definitely one of those things that you know,
there's always some cool new thing in the front end
space every every week or every month, and I think
when it comes to data marketing solutions that sort of
stay quite stagnant for you know, the better part. I
know of pretty much this decade, there isn't really much
(03:20):
I guess, innovation happening in that space. But I think
that there are some libraries starting to emerge, and I've
written one myself as well, that just allow you to
as simply as possible, you know, specify what endpoints your
front end application is going to connect out to and
what sort of data you want back from when you
request something from one of those resources, but then also
(03:43):
have the flexibility to say, you know, let's just say
that we're working on a banking app and we want
to be able to pull up a customer that you know,
maybe they've got three different accounts or three different bank accounts,
two of them are in credit, one of them's in debt,
and they've got a late pain. And if you don't
have some sort of data marcking solution in place for that,
(04:04):
you need to tink around with databases, or you need
to have some test account that could be in whatever state.
And I think being able to really quickly and reliably
manipulate application state without having to mess around with databases
or connecting out using real customers in production or your
staging environments and things like that, I think that that's
(04:25):
sort of like a very overlooked thing in the front
end space. I think it's so handy and it's such
a nice developer experience when you start to contribute to
someone else's code base and all you have to do
to be able to get things up and running is
clone their code and stare dependencies and immediately you can
start doing things with it. Rather than having to ask
a lot of questions about how can we pull up
(04:45):
the application in a particular state.
Speaker 5 (04:48):
Just have one question here. What would be the challenge
if you want to sync like your remugs with your
real API, like keeping it use like the same I
don't know, like furies in open API or as ry. Yeah,
is this like a challenge? What's the cost?
Speaker 4 (05:03):
Yeah? So it is a challenge. I think you've you've
got two different routes sort of down this path. One
of them is that you just accept that there is
the possibility that your your data, like your your local
data and your MAX might get out of sync. And
you'd sort of hope that someone would notice that that's
not foolproof, and you know that can obviously lead to
(05:24):
problems because you're developing it gets one thing locally and
that's not what's in your staging or production environments. There's
also tooling out there that can allow you to sync up,
as you mentioned before, like Swagger specifications and generate mocks
off the back of that. There's loads of things that
do that, and I think that I'm starting to see
a little bit more use of it around the place,
(05:45):
Like even in my current workplace. The other day, someone
came up to me and was like, Hey, check this out.
You can actually generate, you know, a mock server off
the back of a Swagger specification, and it's really cool
to see people doing that. I think that it is
probably one of the biggest challenges in this space though,
because people really like actual data, or at least data
(06:06):
that looks like it could be production data. Like you
don't want random garbled strings for people's names and addresses
and and really large numbers for things like a banking
banking app, where realistically the numbers are a lot smaller
than things like that. So yeah, it is a real challenge,
but I don't think it's an insurmountable one.
Speaker 3 (06:27):
Okay, so sorry if I miss that before.
Speaker 6 (06:31):
But what are the steps, Like, what do the listeners
can do in order to start and benefit from it?
Speaker 4 (06:39):
Yeah, I mean the first thing that I'd probably say
is if you're connecting out to a production or staging
service to develop your apps locally, I'd probably recommend downloading
any mock library. Yeah, anything that there's loads of them
off at NPM I've written one called data Marks that's
starting to get a bit of a bit of traction
at the moment, which is really good. I'm seeing contributions
(07:02):
from the community, but just getting one of them. I mean,
there's loads of really really popular ones as well. You've
got things like Jason Server, which I mean, I'm not
one hundred percent sure how many hits that gets, but
it must get at least one hundred k downloads a week,
and just get your application to connect out to that,
and I think you can immediately start seeing the benefits
of it. Like a lot of these mocking solutions as well,
(07:25):
they don't even spin up. Not a lot of them,
but some of them don't even spin up like an
extra service. Like you've got data Marks, which is as
I said, the library that I wrote earlier, it leverages
intercepting fetch and h XHR requests, so not even running
an extra service. So if you've got a really low
(07:45):
end laptop like myself, which really struggles to run most things,
you know, it's not an extra thing, which is like
chewing up your CPU and battery.
Speaker 6 (07:52):
Yeah, first of all, all someome job on grading the library,
and I just want to clarify the term is thrown
around a lot, and it means several things in the
world of testing. So just to clarify it, we're talking
about fake data.
Speaker 4 (08:10):
Yeah, that's a really yeah, that's that's a really good point. Actually, Yeah,
that that term does get thrown around in the testing
space a lot. Yeah, we're talking about, yeah, fake data.
So we have a request, you know, to Dave's cool
api dot com slash foo, and when we hit that endpoint,
we're expecting a particular response back, and that response is
(08:31):
what I'm referring to as the market it's the mock
response to that request.
Speaker 3 (08:35):
Yeah, so that's a differentiate in like testing.
Speaker 6 (08:38):
When we're talking about mark smock objects, we're usually talking
about like stuff that has assertions.
Speaker 3 (08:45):
Built into them, so if you don't get the stuff
you you expect, it throws an error.
Speaker 6 (08:52):
But when you talk about just getting like fake data
or just like you know, just running a method and
not like doing anything just so it will satisfy the compiler,
we're talking about stubs. So that so just like getting
the data just to display on the screen the list.
Speaker 3 (09:11):
Of puppies that you want to display.
Speaker 6 (09:13):
It's probably it's more like like a stub to those
on you of you who know like that term, So
that's what we're talking about, like fake data, And just
to clarify.
Speaker 1 (09:23):
Yeah, no, that's a that's a very very good point there. Yeah,
definitely right, and that you know, just to reiterate that.
The idea then is, yeah, then you don't have this
back end system that's chewing up more CPU or memory
and you can just focus on your Angerer app.
Speaker 4 (09:38):
Yeah. And I find that not having it because I mean,
it really depends the sort of developer you are and
what where your interests lie as well. But I think
I see it in a lot more junior people as well.
As you know, you're working on a you know, you
might be on a product team at work, and your
team might be split one of many ways, but you
might have front end specialists and back end specialists in
(09:59):
your team. And I do notice that there are certain
I guess there are certain types of developers that like
prefer to stick into their own space, so they prefer
not to have to write endpoint like back and end
points themselves, or maybe they just don't know how to
or whatever. I find that sometimes you hear things like oh,
(10:19):
I can't work on that yet, because the API is
not ready for that yet. And that's one of the
perfect use cases for using these sorts of things is
that you don't actually require a single line of back
end code to be written, and you can already complete
the front end components without a single line of back
end code being written.
Speaker 3 (10:39):
Yeah, that's a very good scenario for that.
Speaker 6 (10:42):
Have you talked about again, sorry if I mean, say,
I had some technical issues with like audio and stuff,
so I didn't hear some of the earlier comments. Did
you talk about what happens once you have the data,
like the real data, do you like still integrated or
just at that point you just like lose the mock
(11:03):
data and then switch over to using the you know,
the real one, or like, what's this strategy there?
Speaker 4 (11:10):
I guess the strategy there is that whatever solution that
you're using, is that you would only really want to
be using these mocked responses when you're developing your application locally,
so that when you're making a build for your staging
a production environment, that you're you're no longer using these
these mock services anymore. So there's a few ways that
(11:32):
you can do that, Like in the entry points to
your application, you can always do a check to see
if you're in a development environment, and then from there
you can dynamically choose to dynamically import your mock libraries
or your mock services, and then that way it doesn't
affect your bundle size when you're making production builds and
things like that.
Speaker 3 (11:52):
Cool nice.
Speaker 6 (11:53):
And for testing, like let's say, unit tests and stuff,
do develop weed that or you just just for development purposes.
Speaker 4 (12:03):
I've found that the strategy that works me is just
using it for development purposes, because when you're writing unit tests,
you know, most of the time i'd gather you know,
you're not necessarily writing unit tests that are unit testing
things that make HGTP calls. And if you are, that
is a simple thing that you could use now I'm
(12:24):
using the term I guess again, but you could use
a mock library for that. For instance. You know, if
you're using jest or mocker or anything like that, you
know you could mock those directly in your unit tests.
Speaker 2 (12:38):
You can also have your CI run your end end
tests and.
Speaker 6 (12:40):
Yep, yeah, most of them. You probably wouldn't want to
unit test your outer layer of your client app. You
probably want to write integration tests there just to see
that your client is talking with the back end in
the right way, and it's not like really helpful to
(13:03):
you know, mock up stuff that you don't really you
can really control. But that's the topic for another episode.
Speaker 3 (13:11):
I guess.
Speaker 4 (13:12):
Yeah.
Speaker 5 (13:13):
I got a question, like before like diving into like
the testing part. If we dive into it, if we're
like developing the app and creating like this fake data,
would you recommend having like a fake data set for
the whole app or do you have like fake data
sets for each context? So like, okay, let's let's suppose
(13:37):
we're in this state and I'm going to load this
fake data and I'm going to try my app with
this fake data, or do you have like global fake
data that you use all the time.
Speaker 4 (13:48):
I found that maintaining a list of like I refer
to them myself just as fixtures. It's probably not quite
the right term for it, but basically, I mean it's
sort of a little bit of both. I've found that
you know, you've got your in the library that I've written.
I refer to them as scenarios, so the application will
have I guess what you would refer to as the
(14:09):
default scenario. So that is like your happiest path that
your application could have. You know, you use the logs incorrectly.
You know, they can view their account information, they can
make you know whatever changes they want, and there's no
sort of error states or weird edge case states. And
then you introduce the concept of a scenario, which is
(14:30):
sort of starting to handle these edge and error cases.
And I've seen different libraries handle these things different ways,
but usually at the end of the day, you define
your default scenarios or like your your happiest path for
how you use your application, and then these scenarios get
merged into that so that you get everything that happens
(14:50):
in your default scenario plus whatever you define in this
edge case, maybe there's like a maybe there's like a
log in error or something like that, or maybe that's
not the greatest example. Maybe we're already logged in, so
that's part of our happy path, and maybe when we
try to view our account information for account number two,
there's some sort of five hundred error from the server,
(15:12):
so that would be part of I guess the set
of mocks for that edge case scenario or error case scenario.
And then when you're using your app, when you're developing
your app locally and you're trying to test that out
and see how things behave you know, you'd expect that
your app would probably do have some something to handle
what happens when we get some sort of error from
(15:33):
the server.
Speaker 5 (15:34):
Thanks, that's a very good question. This, Thank you very much, Shy.
I'm trying hard.
Speaker 3 (15:41):
I know I'm here to support.
Speaker 5 (15:43):
Thank you. Let's still have another question, can I go,
yeah on a roll? Okay, so it's quite the same topic, like,
would you like considering in developing like an angler app
and and I want like some fake data for my
happy past? Would you recommend using a fake library like
(16:06):
yours to have like fake HCP responsors or would you
recommend fake services with the same interfaces and like that?
Can I don't know, change the data in memory or
in a store or anything.
Speaker 4 (16:19):
So that Yeah, that was an interesting that's an interesting one.
So how this all started for me is I had
this problem for the first time, which was, Hey, I'm
starting a new application from scratch, and I don't want
to have to talk to services that you know, either
exists in a live environment or they haven't been written yet.
And that's I sort of got led down that path,
(16:40):
and I was introduced This is back when I was
still writing Angular JAS, and I was introduced to a
library called Angular Multi Marx and that does it basically
behaves the same way that data Marx behaves, except data
Marx is framework agnostic. And so when I was writing Days,
(17:01):
I think I first used it for a React application.
I'm not sure if I'm allowed to say React or
if that's going to get beat down for me. Yeah,
I'll get dumped from the coal in a second. And
I remember it working really nicely because to sort of
like bootstrap a React application. It's slightly lighter on code
than what the Angular Cli generates. But the truth of
(17:24):
the matter is that it doesn't matter what framework you're
using or anything like that. There's always an entry point
to the application, and the developer almost always has access
to that entry point. And for instance, the way that
data max works with it is all you need to
do is call a function called inject max and you
(17:44):
through to that function. You pass through the set of
scenarios that you want to use with your application. So
it's very unintrusive. So I guess to answer your question, yeah,
I would recommend using something like data max or something
that if you prefer to go down on the path
that has something that actually spins up something like a
node service or any HGTP server. You could use something
(18:07):
like a Jason server or API mocker, or you know,
there's there's so many different things, but it's an unintrusive
way of integrating it with your application while still having
that freedom to have I guess the idea is when
you build or deploy it to a different environment that
you're not stuck with that mock solution. You can sort
(18:28):
of build it out of your application as well.
Speaker 5 (18:31):
Okay, so your recommand are like to use fake data
at the HTP level, so it's framework agnostic and you
can reuse it somewhere else.
Speaker 4 (18:41):
Okay, yeah, absolutely, And it just it makes life so
much quicker and easier, especially if you're trying to prototype
something or spin up a new project that you know
it's going to stick around for a while, or even
if it's not yet as just said, even if it's
just prototyping. I just think that it's such a fast
way to get code written and immediately start you know,
(19:03):
really being able to focus on the front end space.
Speaker 5 (19:06):
Thanks.
Speaker 1 (19:06):
Yeah, so what's the cycle that you follow. I mean,
are you're doing TDD. Are you you know, build test,
build test.
Speaker 4 (19:14):
Yeah, that's a that's a good question. I'd probably be
lying if I said that I always do TDD. But
possible blasphemy again, but.
Speaker 3 (19:23):
That's for me.
Speaker 2 (19:26):
Shy is the only one you'll make cry with them. Sorry,
I'm gonna leave.
Speaker 3 (19:30):
No.
Speaker 4 (19:31):
I think it really depends for me on the project
and the nature of the work. For simple crowd applications,
I'm probably less inclined to follow a more hardcore methodology.
For projects that I'm joining and contributing to, I'm probably
more inclined to do it. I find that a lot
(19:52):
more of my work these days. I'm really enjoying a
lot of projects that I contribute to these days, U
Cyprus for the for the UI and all of that,
And I'm really enjoying the idea of writing Cyprus tests first,
so that and making them fail and then building against that.
I find that that's been a really I guess effective
(20:13):
way that works for me. But I think it's such
a difficult question to answer because there isn't a silver bullet.
There's nothing that works perfectly for everyone.
Speaker 1 (20:23):
Yeah, that's a very BDD to me, which is behavioral development,
which is you build the big story first and then
you cycle and you get the steps out with your
unit tests.
Speaker 3 (20:34):
Yeah, yeah, most of that.
Speaker 6 (20:36):
I find that the writing test after the code is
good when you are exploring like a new and you
think that you're still not sure how it looks like
how the API behaved, you don't really know the API yet.
Some people preferred to do it in TDD that like
those scenarios. I find it too confusing because I need
(20:58):
to like focus on the test and learning a new API.
But once I learn, like once I know the API,
I switch the order and then it's much easier to.
Speaker 3 (21:08):
Oh, I know that this is how it behaves like this.
Speaker 6 (21:11):
Library or something like that, or this like thermac, and
now I know how to write my test to test
my logic.
Speaker 3 (21:18):
Only my logic uses this or something like that.
Speaker 6 (21:21):
But I find it also another scenario to use I
don't know if it's that common, but to use like
a fake data libraries like like you mentioned and Jason
server is when doing demos like for talks and for
courses and you know, workshops. That's the best scenario because
nobody has to like now download postgrass or you know,
(21:45):
install like a database or even know what like you know,
it reduces all the complexity, So that's another good use case.
Speaker 4 (21:54):
Absolutely it's a sort of education side and the demo
side is absolutely great. You also you're in full control,
like you're reducing the number of points of failure and
reducing the complexity.
Speaker 5 (22:08):
Yep.
Speaker 2 (22:09):
Have you done anything with storybook?
Speaker 4 (22:11):
Yeah? I love storybook. I've just spun up a new
project in the last couple of weeks where we've had
quite a few contributors towards it from the basically day one,
and we've found really really effective use of storybook to
sort of any sort of shared component goes in there
and it's very quick. You know, I can say say
to the gang, you know here, I've developed this. It's
in storybook. You can use it if you want, or
(22:33):
you can you can tweak it. So I've found a
lot of success and it's also in the past as well,
but this has been the most effective sort of use
of it I've seen where you've got loads of developers
from the beginning on something and you know, you don't
want to be building the same thing multiple times and
having that soundbox environment from the get go has been
really really helpful.
Speaker 3 (22:54):
Cool.
Speaker 5 (22:55):
We got one little question about consumer driven contract with
I don't know, libraries like BACKED. I don't know if
you're familiar with that, and if you are. For instance,
when I use BACKED, I usually use that in my
integration tests, for instance, and it generates the facts for
(23:16):
the back end. But would that be possible to integrate
that with your fake data library or something?
Speaker 4 (23:25):
It might be. I've not done it myself. I think
I've probably I'm probably falling into the category of people
who haven't seen PAC testing being used very effectively in organizations.
I think that the the theory, like how it works
and what it's used for is like very sound. I'm
just I just don't think that I've really been exposed
(23:47):
to anyone, like any organization that does it well. But
I'm sure there's a million people out there that can
tell me that they love it in terms of using
it with these sorts of like fake data libraries. I'm
not one hundred percent sure whether or not that's I
don't know what the right word is, whether there's a
decence or not yield from that to make it worth
(24:08):
the effort. But maybe the rest of the game here
have some other thoughts.
Speaker 6 (24:13):
Yeah, I think that like the future is in the
connectivity between those two points. Like you already have your
fake data which has a schema you know, like shape,
and you already have like if you're going to I
think that again, the future is in like stuff like Packed.
I don't know if pact itself because it's still like
(24:34):
like in I feel like a proper node server table
like for testing and stuff like that still like uses
the thing the Ruby application behind the scenes, which.
Speaker 2 (24:46):
I can confirm.
Speaker 6 (24:47):
Yeah, so, but the idea behind it I think is
very very very useful, And to those of you who
don't know what it is.
Speaker 3 (24:58):
Check out packed JSPA.
Speaker 6 (25:00):
Basically, it means that you have contract tests between your
client and your server, and when you mock out your
server like with instead of using like just fake data
without any connection to the server side, you actually use
fake data and that fake data and or the contract
is being generated as ad Jason, and then on the
(25:24):
service side they take this Jason and run it through
like as an API call to the server to test
if the server returns what the contract says it needs
to return and if not, you see an integration problem.
Speaker 3 (25:38):
And that's a.
Speaker 6 (25:40):
I feel that's a much more scalable approach rather than
like using integration tests or end to end test because
those can cover just you know, a small chunk of
your logic because otherwise, for an enterprise application, for example,
it can.
Speaker 3 (25:57):
Take like two hours. I don't know to run all
the scenarios and everything breaks all the time, But I don't.
Speaker 6 (26:04):
I feel like we're only just beginning, Like I don't
have like a go to solution now because I think
there's still much more work to be done. But I
feel that PACKED is a cool organization, like the people
behind it.
Speaker 3 (26:18):
They are open, they have a cool.
Speaker 6 (26:22):
No it's not slack, I think it's a guitar channel
or no, they have also a slack channel and very
open to collaborations and contributions.
Speaker 3 (26:33):
So that's my bit.
Speaker 6 (26:35):
But I think the connection between like the fake data
and something like PACKED or contract testing this is the
obvious thing because you.
Speaker 3 (26:42):
Already have it.
Speaker 6 (26:44):
It's like I think they have there's a strong connection
that they want to work now on in trying to
solve which is between story books and unities because both
have use cases, Right, you describe use cases in your storybook,
like which flags can you like turn on and stuff
like that, and now it behaves, which basically the same
(27:05):
setup in the unit test. You set up the same
stuff in the unities. So like the connection between them
is something I'm exploring right now and trying to maybe
do something new with them. But more on that later
on when I have some POC to show.
Speaker 5 (27:23):
But by the way, concern impacts for those who want
to try, like in fact, like shy, Like I don't
know if I'm gonna take it with me on this,
but you know, I'm not a big fan of like
the real implementation because like pacts is really based on
running a packed server next to your app and then
running a PACT client to test your API, which is
not very unit tests and friendly and paralyzation friendly, and yeah,
(27:49):
it breaks a lot and it brings a lot. So
I've been experiencing things where you what I love about
PACT is the pact specification, Like the JSON file that
came the schema is really nice and it says like
I'm expecting this request and I'm going to respond this
if I'm in this state and I'm not aware of
(28:09):
any library. I've just been experimenting things and maybe you.
Speaker 6 (28:14):
Can you're working on something that they will general to
generate the files without going through the server.
Speaker 5 (28:21):
Yeah, the idea is to make something that doesn't especially
doesn't need the client. What I want to mean by this,
I'm not like putting out like I'm not teasing about anything.
I'm just saying that. I'm just saying that Packed. If
you're not satisfied by packed jas like server and all
(28:43):
the perform a didos attack on them, maybe maybe we
need some libraries that handle the specification. So keep an
eye on Like the Packed specification. The scheme is really nice,
and the way they did it, I think there's something.
I joined Chai on this, like there's something we can
we can do there to join, like all this fake
(29:06):
data with the swagger and the fact there is something,
there is something to do.
Speaker 3 (29:11):
This is the future. Yep, you heard it here first.
Speaker 5 (29:19):
I said it before, but I was along with my cat.
Speaker 1 (29:25):
With my cat, we're kind of getting toward the end
of our time. Is there anything else that we should
make sure we cover here?
Speaker 3 (29:32):
How long it took you to grow this beard?
Speaker 5 (29:35):
Dave?
Speaker 4 (29:35):
Oh, yes, you can see this. I'm not too sure
because I do trim it quite a bit. I've thought
it for quite a few years now, most significent, Thank
you very much. I always enjoy a beard conflict. There's
about there's about eighteen chins underneath this beard.
Speaker 5 (29:51):
I think.
Speaker 3 (29:54):
You're you're in good company.
Speaker 1 (29:58):
I'm kind of curious how much how much more quickly
were you able to move using this technique?
Speaker 3 (30:04):
Boller?
Speaker 2 (30:05):
Do you just feel like you're manfester.
Speaker 4 (30:07):
The beard or the mocking solutions.
Speaker 3 (30:10):
Marking the beard the beard? How quickly?
Speaker 4 (30:14):
Yeah, it's much less. I feel like I mean, personally,
it just feels like I'm not blocked by anything to
do with data. I can make it exactly what I
want when I need to. And you know what, you know,
if I am just spinning up a new project and
I'm waiting on some backend work to be done round
waiting on myself to implement some endpoints, you know, I
(30:35):
can right the front end and i can develop my
features or fix my bugs or whatever. And let's just
say that there's nothing in place to enforce any sort
of integrity between what fake data I'm using and what
the actual schema it's going to look like most of
the time, and by most of the time, I mean
ninety nine times out of one hundred, I can take
a pretty good guess at what it's going to look
(30:57):
like anyway. And you know, if it turns out that
there's an extra field that's coming back in the response
body of a particular request that I need to be
mindful of, or I've met like I've given something the
wrong name or whatever, you know, that's a very quick
and easy fix. So I guess to answer your question directly,
it feels many orders of magnitude faster. And anyone that
(31:20):
I've sort of introduced to this or spoken about or
implored to use that's sort of engaged in any sort
of conversation, you sort of you see them have that
sort of moment where they realize just how helpful this
sort of stuff is. I don't really think that everyone
is aware of these sorts of techniques and that they
aren't complicated to set up, and they're not invasive in
(31:41):
your own code base, and you sort of see them
have that sort of Eureka moment, the light bulb turns
on and all of a sudden, this is great. So yeah,
I guess that's probably the best answer that I can
give you for that nice But the way.
Speaker 3 (31:55):
Have you talked about other generating like.
Speaker 4 (31:58):
Yeah, so I'm I'm currently I've just about written a
finished writing a Chrome plug in that I can make
it record and requests that I'm making and capture actual
requests and export them as marks to use nice, which
is really really nice. I'm hoping to get that published
pretty soon and I'll be spamming that on on social
(32:21):
media and trying to get people now in that as well.
Speaker 5 (32:25):
I'm away retweak excellent And by the way, I also
have like a real quick question concerning recommendation. Would you
recommend using like static fake data like as static as possible,
or would you recommend using like some dynamic features like
(32:45):
things we can see with the Jason server, Like would
you hard code like slash user slash user ID and
the response are Would you recommend like writing dynamics stuff
like add some a little JavaScript to the Jason server.
Speaker 4 (33:02):
That's a good question. I guess it depends on what
data you're dealing with. But that sort of leads into
other conversations as well, Like you've got certain things that
you know they're pretty static, like someone's name is pretty static,
someone's account balance is not so static. But even for
the things that are really static, you know, you then
get you then delve into the territory of I can't
(33:25):
remember what the exact term for it is, but you know,
we're talking about, well, what if you've got a really
really long name or really really short name sort of
catching those sorts of boundaries. What happens when your applications
using a language that is, instead of left to right,
it's sort of right to left sort of language. And
you've got those sorts of you know, and now you've
got got to deal with really short and long names
(33:45):
and see how how you interface behaves with that sort
of stuff. So I guess I can't really directly give
you an answer there. Most of the time I tend
to stick with really static things, but I guess it's
definitely very valid ton stead of using a more dynamic
approach as well, it probably helps you test a wider
range of things.
Speaker 5 (34:06):
Thanks.
Speaker 2 (34:06):
Okay, all right, well let's go ahead and use the picks. Shy,
do you want to start us off with the picks?
Speaker 6 (34:13):
Yeah?
Speaker 3 (34:13):
Yes, Jack.
Speaker 6 (34:17):
First of all, I want to pick so Angikov did
this live call when they talked about IV and how
to prepare to angular for angular and nine how to
prepare right now before the announcement, so check it out.
Speaker 3 (34:36):
I will put a link.
Speaker 6 (34:37):
And also recently I retweeted or I tweeted this short
video by Angela you where she talks about her approach
to like focus on things you can change and be
in a role model. Really cool short video teaches I
(34:58):
think iOS and how to develop apps for mobile.
Speaker 3 (35:03):
So I'll put that as well. And those are our.
Speaker 2 (35:07):
Picks nice units you have to picks for us.
Speaker 5 (35:12):
So I have this link. It's Chase on generator dot com.
It's just I thought about it because it's related to
the topic, like it's really nice. I don't know if
you know about it. It's a little online tool to
generate fake data that doesn't look like full bar, you know,
something more realistic. It has generators for company names and
(35:35):
cities and things like that. And the other the other
pick is a random code from canspeg like father of
Extreme Programming, which is quite related to what we're talking
about here today about tests and things like that. It
just says like that developing an application is just like
a boat with a hole in it. If you keep
(35:58):
rowing like you end up under the water. But if
you just keep on like taking the water out of
the boat. You're not moving, so it's like an equilibrium.
And that's what I like about the approach of Dave Cooper. Okay,
we're not like TDD and everything. We're not just like
it's not perfect, but anyway, we're moving forward, we're moving fast,
(36:19):
and we're keeping it clean anyway, you.
Speaker 3 (36:21):
Know, awesome.
Speaker 6 (36:21):
By the way, I want to mention that Canback has
a nice little video series now on YouTube on his
channel where he talks about testing. You need testing, I think,
And one thing that he mentioned which really makes make
sense to me was not treating your code, your testing
(36:43):
code as production code, which is countering most beliefs that
I heard before, like keeping your tests dry and all
that stuff. It actually creates more problems when you try
to keep things dry and you end up not understanding
what the tests are doing.
Speaker 3 (37:00):
So that's kind of a nice way.
Speaker 6 (37:02):
And now this and I don't know counter approach to
look at your tests and try not to dry everything
and make everything you still just think about what you
are drying and what you're keeping in like in front
of the developer who write the test or maintain the test.
Speaker 3 (37:20):
So that's one thing.
Speaker 6 (37:21):
And by the way, I've forgot to mention in my piks,
let me like hijack one quick. I have like a
free workshop on like the types of tests and stuff
like that, so you could like sign up on testangler
dot com and when it will be released again you
will get a entification. But I'm talking there about like
you know, the contract tests and all the stuff that
(37:42):
we talked about this episode. Just forgot about it. So yeah,
testanglar dot com.
Speaker 2 (37:47):
And that's it for me, Nice Unice, anything else from you?
Speaker 5 (37:52):
Oh, that's it for today.
Speaker 3 (37:53):
Okay.
Speaker 1 (37:54):
I'm always like eager to go and then I'm like,
am I cutting them off? So awesome. I've got a
couple of picks here. The first one is Man on
the other shows I've been doing Christmas movie picks, but
I think we might be a little bit too late
on that. I'm gonna throw it out anyway, and we'll
just see where it goes. If you get this right
after Christmas watch them anyway. So I'm just gonna pick
four or five Christmas movies that I really really love.
(38:16):
These were spread out over several weeks on like JavaScript
jabber and stuff, so if you've already heard them, I'm sorry.
Speaker 2 (38:21):
But there you go.
Speaker 1 (38:22):
Some of the movies that I think everybody should watch.
I think my favorite one of all time is A
Christmas Story, and that's just a classic movie, tons of
one liner's funny scenes.
Speaker 2 (38:32):
I mean, just a terrific movie.
Speaker 1 (38:35):
So if you haven't seen it, I think it came
out in nineteen eighty three, definitely check it out.
Speaker 2 (38:39):
And then the.
Speaker 1 (38:40):
Rest of these are going to be a bit older.
The first one's called Holiday Inn. It's the first movie
in which the song White Christmas appeared. And yes, there
is a movie called White Christmas. Both movies actually have
Bean Crosby in them, and he sings the song in
both movies. They're both terrific. One was made in the
forties and one was made in the fifties. Holiday Inn
(39:00):
has Being Crosby and Fred Astaire in it, so a
little bit more dancing and zinging and stuff. There is
plenty of singing in White Christmas though, and it features
Danny Kay, and Danny Kay is hilarious. So if you
want to go look up other older movies that are
worth watching that are freaking funny, just go find anything
with him in it, because they're awesome. And then another
(39:21):
one and This is an old movie. It's a Kerry
Grant movie. It's called The Bishop's Wife. Basically, it's this
bishop he feels called to build the cathedral in the town,
and so this angel appears and you know, kind of
interacts with him and his wife. Anyway, it's a terrific movie.
I'm not going to spoil too much more of it,
but yeah, it was pretty awesome. And then my mom
(39:44):
took us all to see Frozen two, so I'm going
to pick that. It's not a Christmas movie, but it
was terrific and my favorite part was the Lost in
the Woods song. If you grew up as part of
my generation, you'll enjoy it. That's all I'm going to
say about that. Dave, Do you have some picks for us?
Speaker 4 (40:00):
Yeah? I was going to be really self indulgent and
just pick the Mocking Library that I wrote as a pick,
but no, no, no, no, no, I can't do that.
Speaker 2 (40:11):
And then pick that mouse all right, I'll pick.
Speaker 4 (40:13):
That Data Marks. You can get it off NPM. If
you do, give it a go, and if you love
it or hate it, please let me know. I'm always
up for contributions or discussions or suggestions. I love all
of that stuff. But I think I'll pick another thing
which is not along these sorts of lines. But I've
(40:35):
recently just returned to working after about three and a
half months off because my baby was born and I
had the opportunity to take some time to time off
work to sort of learn how to take care of
a human. But during that time I got really big
into baking bread and it's unbelievably satisfying putting in the
(40:58):
effort and the hours to getting a really good loaf
of bread baked. So there's a guy who lives in
Bath in the UK called Richard Bertone, and he's got
a book called Dough and that would be my pick.
I've done a bread making course with him before, but
he is like the bread god. He really understands all
(41:19):
of that stuff. So my pick will be baked some
bread and read that book.
Speaker 5 (41:25):
Nice.
Speaker 1 (41:26):
I love cooking. So yeah, that's right at my alley.
If people want to find you online, where are you?
Speaker 4 (41:32):
I'm on Twitter. I'm not super active, but that's just
because I don't think many people want to read my ramblings.
But my Twitter handle is at Dave Wright's Codes with
an S on the end. There you can also see
my blog at Dave Cooper dot org or shoot me
an email on Dave at Davecooper dot org.
Speaker 1 (41:52):
Nice, all right, well we'll go ahead and wrap up,
but thanks for coming and talking to us.
Speaker 4 (41:58):
Yeah, thanks so much for having me.
Speaker 2 (41:59):
That was a lot of fun and thanks for filling
in with this unis.
Speaker 5 (42:02):
Thank you, thank you for having me.
Speaker 1 (42:04):
All right, folks, Well, yeah, we'll have another one next
week and in the meantime max out
Popular Podcasts
CrimeLess: Hillbilly Heist
It’s 1996 in rural North Carolina, and an oddball crew makes history when they pull off America’s third largest cash heist. But it’s all downhill from there. Join host Johnny Knoxville as he unspools a wild and woolly tale about a group of regular ‘ol folks who risked it all for a chance at a better life. CrimeLess: Hillbilly Heist answers the question: what would you do with 17.3 million dollars? The answer includes diamond rings, mansions, velvet Elvis paintings, plus a run for the border, murder-for-hire-plots, and FBI busts.
Crime Junkie
Does hearing about a true crime case always leave you scouring the internet for the truth behind the story? Dive into your next mystery with Crime Junkie. Every Monday, join your host Ashley Flowers as she unravels all the details of infamous and underreported true crime cases with her best friend Brit Prawat. From cold cases to missing persons and heroes in our community who seek justice, Crime Junkie is your destination for theories and stories you won’t hear anywhere else. Whether you're a seasoned true crime enthusiast or new to the genre, you'll find yourself on the edge of your seat awaiting a new episode every Monday. If you can never get enough true crime... Congratulations, you’ve found your people. Follow to join a community of Crime Junkies! Crime Junkie is presented by audiochuck Media Company.
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.