Agile Practitioners Conference

When we're talking about testing APIs, we usually think about the results as either working or not.
But APIs are like windows into our system, and sometimes, these windows are open too much. When that happens, they might expose more information than they need. There is such thing as Too Much Information with APIs.

And that's the topic of my next video.

Enjoy!
https://youtu.be/8VVhbtpNDCQ

The API Series - TMI In this series, I'm talking about APIs and API testing. In this one, I talk about APIs that expose too much. And as testers, we need to make sure they don't ...

When we're thinking about code, it's written in a single language. After all, it was written in Java, right? I don't expect to find Python functions in there.

But we are lying to ourselves. There is usually more than one language in our code. If we compare our application logic code, to using a framework, we automatically understand it differently. Instead of users, books, and buying, we see in the code the use of files, handles and error catching.

Unless you work really hard to abstract the platform code, your code looks like that. And every framework adds its own dialect.

While these multi-lingual skills seems handy, it's one of the major source for bugs - translation errors.

Tests are no different. In fact, out of the box, we're using test frameworks. They have fixtures and asserts. Then we add our application language. Bugs in tests is something we'd like to avoid, we have enough of those in the code.

With a bit of work, we can make test code much cleaner. Readable, trustworthy, and maintainable. I'll show you in my "Clean Tests" webinar this week. Twice in fact, and it's FREE.

Register here.

Europe: Nov 29th, 10am https://us02web.zoom.us/webinar/register/1816952877167/WN_n0b6sAsiQsGbP1If4xUFvw
US: Nov 30th, 1pm ET https://us02web.zoom.us/webinar/register/3616990936213/WN_vzlwl9wSTmWgiUGq2TvuTA

When we're testing, we're looking for clues and evidence. Those either confirm or contradict our assumptions on how the system should behave.

In API testing, we still need those. But the clues need to point not about the expected behavior of the API. I mean, it's nice to have those, but users don't use APIs. They use features (that may call APIs). Evidence that the API works, doesn't prove that the feature works.

In the "But Does It Really Work?" series of blog posts, I look at how to raise our confidence that an API, and its feature works.

Here's the first bit:
https://www.everydayunittesting.com/2023/10/does-it-really-work-testing-api-calls-part-i.html

When does code become "legacy code"? And when do tests go through that process?

We usually put the "legacy" ribbon on code that we got from somebody else. Someone who doesn't think like us, doesn't communicate like us. Someone who speaks a different language.

We are fortunate(?) to be handled their legacy.

The truth is, sometimes that somebody is past us. And sometimes, it doesn't take too much time to look at code, and ask "what was I thinking?". Sometimes, in shock, sometimes literally.

We are time travelers. At the end of each day, we have more experience, better understanding and more information about our system. Yet the code stays the same.

Join me for the "Clean Tests" webinar to learn how to make test code live longer and better. And for us to spend less time in test-maintenance mode.

Register now.

Europe: Nov 29th, 10am CET https://us02web.zoom.us/webinar/register/1816952877167/WN_n0b6sAsiQsGbP1If4xUFvw
US: Nov 30th, 1pm ET https://us02web.zoom.us/webinar/register/3616990936213/WN_vzlwl9wSTmWgiUGq2TvuTA

People ask me about learning unit tests, or API tests. They want to improve the skills of their developers and testers. While I'm happy to oblige, that's not always what they need.

Learning how to test, refactor, report - those are all important skills. But they serve a higher purpose - improving delivery speed, while retaining the same level, or improving quality.

Mostly, a process-oriented analysis is more important than local improvement. Finding the quality bottlenecks. While the requested skills can use improvement, maybe there are others that are more important to do first.

If you want to an objective look at your process, let me know. I can help with analyzing the process, identifying what's needed, planning the implementation of the process, and of course with the practical details.

Ping me.
https://www.everydayunittesting.com/contact

,

APIs are complex. Testing them is complexer. Yes, you it's a word.
Since REST APIs are based on HTTP and HTTP is based on text, you can play with what you send to see if the system can handle it.

Let's take white space for example. If you're sending JSON or XML, whitespace shouldn't matter. As long as the right non-space-y characters are in order, the server will be able to read it, right?

There's a hidden assumption (that most of time is true, that's why it's tricky). Most frameworks you use in the back-end will do the transformation from JSON to objects for you. That means they handle the "ignore the white space for you". In special cases, the developers will build the white-space filtering.

Most of the time it works. But bugs can happen. Now, what is the risk of that happening?

In the first case - low, in the second higher. The lesson is that you need to know how things are built, before deciding how to test and what.

And I made this video, on how else you can play with input data. Also visible characters.

Enjoy.
https://youtu.be/-_dCrwnUUxk

The API Series - Testing Fun With Input Data In this series, I'm talking about APIs and API testing. In this one, I talk about how we test for different responses for the same API, just by playing with ...

We usually look at comments as a code smell. They are not functional bugs, but they have maintenance costs.

Bad comments either repeat what code does, don't explain it very well, or in the worst case, are not updated when the code is updated. That's where the maintenance cost comes: When we go in, we spend more time in the code, until we get out.

Does this apply to tests? Yes. First, if you put comments in your tests, you go back to the maintenance issue.

Next, test names. Comments are not checked by compilers or linters, so if you change the code, you need to remember to change the comments too. Same goes for test names. If you change the test workflow, you need to make sure the test name corresponds to that workflow. I failed this many a-times.

Sometimes test names are full comments. In JavaScript or Groovie, and other languages, test names can be a whole story, all inside a long string no one checks (unless the code reviewer remembers).

Good test names help us. Bad test names give us the comment pain.

In the upcoming webinar, Clean Tests, I'll be talking about clean code issues in tests, and how to solve them.

Register now.

Europe: Nov 29th, 10am CET: https://us02web.zoom.us/webinar/register/1816952877167/WN_n0b6sAsiQsGbP1If4xUFvw
US: Nov 30th, 1pm ET https://us02web.zoom.us/webinar/register/3616990936213/WN_vzlwl9wSTmWgiUGq2TvuTA

I learned a valuable lesson with the "Postman in an hour" webinar - Introduction to Postman, the light and dark sides - Check the edge cases.

When I scheduled the two webinars, the US one fell between Europe and US transition from Daylight saving time to the "dark times". No worries, I took that into account, checked it, and it looked ok.

The problem was a month later, the actual due date. Turns out although the webinar started on time, the my calendar was set for an hour later.
So imagine my surprise getting ready for the webinar, and discovering it should already have been started half an hour ago.

So first, I apologize for the people who registered, arrived, and waited. I hope the recording here can make it up.

Also, the next webinar "Clean Tests", I'm doing twice (29-30 Nov). Again. On time. And I've already started checking every if it had already started.

Here's the recording.
https://youtu.be/VQtQ_dvXMg0

Postman In An Hour (or so) - Webinar recording Interested in Postman? Want to know if it can help you?In this session, I'm looking at Postman, the API testing tool. I'll go over what APIs are and how they...

The final part of my "Postman VS CUrl" series, describes a surprise. While both tools don't hide information, they do work differently. If you're not careful, you might miss important information. Even worse, if you miss it, you might fail or pass a test by mistake.

Check it out.
https://www.everydayunittesting.com/2023/10/requests-under-the-hood-curl-vs-postman-part-3.html

CHECK OUT OUR NEW WEBSITE: https://practicalsw.com

Sep. 2022: UPCOMING EVENTS
● Agile Knowledge Management: Ilan Kirschenbaum
● Microservices Done Right: Uri Goldstein
● Docker for Developers: Dror Gluska

For more info: Dalit Dasht
[email protected] | 052-357-7844

ספוטיפיי שינתה את תעשיית המוזיקה, את זה כולם יודעים. אבל רק לחברי קהילת האג'ייל הישראלית ניתנה ההזדמנות לשמוע אתמול בערב מנדב (סיימון) כהן, שעד לאחרונה היה דירקטור הנדסה בספוטיפיי, על המודל המפורסם שאפשר לספוטיפיי לחדש, להתנסות וללמוד מהר בשוק תחרותי. היה מרתק!
תודה מיוחדת לנדב כהן, שעביר הרצאה מרתקת וענה בתשומת לב לשאלות הרבות של המשתתפים, תודה ענקית לחברת "אובר-וולף" על האירוח המושלם, ותודה לענת אלון ונעמה גפני-ליפשיץ, ממובילות קהילת האג'ייל הישראלית, על שגרמו לערב הזה לקרות.
אם אתם עדיין לא חלק מהקהילה - הצטרפו עכשיו שלא תפספסו גם את המיטאפ הבא:
https://lnkd.in/dpt5PbS https://lnkd.in/dBMatMN

Many thanks to: Nadav Simon Cohen, Overwolf, Anat Alon, Naama Gafni Lifsh*tz

אלפי תודות על מיטאפ מוצלח במיוחד שנערך הערב בחברת סייברארק. במיטאפ, פרי שיתוף פעולה בין חברת סייבראק וקהילת האג'ייל הישראלית, חלק עמנו דניאל שוורצר כיצד הצליח להאיץ ולשפר חדשנות הנדסית באמצעות מבנה יחודי של גילדות.

תודה לדניאל על שחלק עמנו את חזונו בהרצאה מרתקת, קולחת, ולעיתים משעשעת.

תודה לעומר מישר, על אירוח המיטאפ, על שלל הפינוקים ועל שיתוף הפעולה עם הקהילה.

תודה לנעמה גפני-ליפשיץ, ממובילות קהילת האג'ייל הישראלית, אשר נטלה על עצמה את הצד התפעולי.

אם אתם עדיין לא חלק מהקהילה - הצטרפו עכשיו שלא תפספסו גם את המיטאפ הבא:
https://www.meetup.com/Agile-Practitioners-Israel
https://www.linkedin.com/groups/81807/